Engenharia de Software: Conceitos e Objetivos

Prévia do material em texto

Engenharia de 
Software 
Engenharia de 
Software 
1ª edição
2019
Autoria
Parecerista Validador
Juliana Padilha
Sandra Gavioli Puga / Paulo Lacerda
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. Nenhuma parte
desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A violação dos
direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
4
Sumário
Unidade 1
1. Introdução à Engenharia de Software .......................7
Unidade 2
2. Modelos do Ciclo de Vida do Software .....................18
Unidade 3
3. Engenharia de Requisitos e Modelagem 
de Software .....................................................................30
Unidade 4
4. Projeto de Interface Homem-Máquina ................45
5
Palavras do professor
Esta disciplina tem por objetivo apresentar os aspectos do software 
enquanto produto, abordar os conceitos e fundamentos da Engenharia 
de Software enfatizando principalmente os diferentes tipos de softwares 
existentes.
É imprescindível que você, aluno, faça o uso de todos os materiais 
disponíveis na plataforma, realize os exercícios propostos, participe dos 
fóruns de discussão e leia os materiais complementares indicados. 
Bons estudos!
6
Objetivos da disciplina
• Definir software, processo de software, requisitos de software e as 
técnicas de interface homem-máquina.
• Classificar os tipos de modelo de processos existentes na literatura;
• Identificar os requisitos funcionais(RF) e não funcionais de um 
software(RNF).
• Demonstrar o entendimento dos requisitos funcionais (RF) e não 
funcionais de um software (RNF) através da transcrição do texto 
para modelos gráficos (UML).
• Avaliar interfaces de sistemas computacionais que favoreçam a 
interação com o usuário.
7
 1Unidade 1
1. Introdução à Engenharia de 
Software
Para iniciar seus estudos
Esta unidade apresenta uma introdução à engenharia de software e 
fornece uma base para a compreensão do restante da disciplina. Assim, 
trabalharemos os principais conceitos presentes na engenharia de 
software, como:
• O que é engenharia de software e qual a sua importância nos dias 
atuais.
• O que é software e quais são os diferentes tipos de software 
existentes.
• E, por último, uma breve descrição do que é ética na engenharia 
de software.
Objetivos de Aprendizagem
• Explicar os conceitos de software e softwares como produtos.
• Diferenciar os tipos de software existentes na literatura.
• Identificar e discutir a importância da engenharia de software.
• Discutir as questões éticas e profissionais importantes para os 
engenheiros de softwares.
8
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
Introdução da unidade
Nesta unidade, apresentaremos conceitos que lhes permitirão entender o que é a engenharia de software, qual 
a sua importância, o conceito de software e os diferentes tipos de software existentes atualmente e também uma 
breve descrição do que é ética na engenharia de software.
1.1 Software como produto
O software pode ser considerado tanto um produto quanto um serviço. Quando ele é considerado um serviço, 
a tecnologia é ponte para a real necessidade do cliente. Como exemplo temos o serviço de armazenamento na 
nuvem, em que o software é um mero meio para o compartilhamento e armazenamento de dados do usuário. 
Normalmente, nessa forma de comercialização, o software possui uma temporalidade associada a um custo 
mensal ou anual. 
Em contrapartida, o software como produto é, por si só, a materialidade da vontade do usuário. Nesse caso, temos 
como exemplo as ferramentas de produtividade (Ex: Microsoft Office), sistemas operacionais (Ex: Windows, 
Linux), e aplicativos (Ex: Moodle). 
Nos últimos anos, devido à evolução das redes de computadores e ao barateamento dos recursos computacionais, 
como também à necessidade de disponibilidade onipresente da Tecnologia da Informação (TI), observa-se uma 
tendência de comercialização de softwares como serviço1.
1.1.1 Definindo o software
De acordo com Pressman (2011, p.11), “software consiste em:
• instruções (programas de computador) que, quando executadas, fornecem características, funções e 
desempenho desejados; 
• estruturas de dados que possibilitam aos programas manipular informações adequadamente;
• e informação descritiva, tanto na forma impressa como na virtual, descrevendo a operação e o uso dos 
programas”. 
Para Sommerville (2011, p.4), “softwares são programas de computador e documentação associada. Produtos de 
software podem ser desenvolvidos para um cliente específico ou para o mercado em geral”. 
1.2 Atributos de um software
Conforme visto, software não é apenas um programa; ele inclui também toda a documentação produzida durante 
o seu desenvolvimento. Existe um conjunto de atributos que são considerados essenciais para o desenvolvimento 
de softwares profissionais. Atributos de software refere-se as características desejáveis que um software deve ter. 
1 Software como serviço também é conhecido pelo acrônimo SaaS (Software as a Service).
9
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
No entanto, esses atributos dependem do tipo de software que está sendo desenvolvido. Por exemplo, um sistema 
bancário deve ser seguro, um antivírus deve oferecer proteção contra vírus e assim por diante. 
Esses atributos são sumarizados a seguir (Sommerville 2011): 
• Manutenibilidade: o software deve ser escrito de forma que permita a evolução para atender às 
necessidades dos clientes.
• Confiança e proteção: um software deve ser confiável, ou seja, não causar prejuízos físicos ou econômicos 
no caso de falha do sistema. Em termos de proteção, o software deve garantir que usuários maliciosos não 
sejam capazes de acessar ou prejudicar o sistema. 
• Eficiência: um software é eficiente quando ele responde rapidamente às ações dos usuários e não 
desperdiça recursos do sistema, como memória e tempo de processamento. 
• Aceitabilidade: este atributo refere-se a aceitação por parte do usuário, ou seja, o software deve ser 
desenvolvido de acordo com o tipo de usuário (crianças, adultos). Por exemplo, um software para crianças 
requer mais cores, mais imagens e é mais fácil de interagir. 
1.3 Características do software
O software possui características diferentes das encontradas em equipamentos físicos (hardware). A seguir 
apresentaremos as três características definidas por Pressman (2016):
1. Software não é fabricado no sentido clássico: O desenvolvimento de software e a fabricação de hardware 
possuem algumas similaridades como: a alta qualidade é obtida por meio de um bom projeto; ambas as 
atividades são dependentes de pessoas e requerem a construção de um “produto”. Os custos de software 
concentram-se no processo de engenharia, portanto, projetos de software não podem ser geridos como 
se fossem projetos de fabricação. O processo de engenharia diferencia-se do processo de fabricação 
pelo caráter inovador. O processo de fabricação é repetitivo, pois a produção entrega sempre os mesmos 
produtos. O processo de engenharia é sempre inovador ou personalizado (por exemplo para atender as 
necessidades dos clientes), assim cada produto (software) produzido é único. 
2. Software não “se desgasta”: Softwares não são suscetíveis aos mesmos problemas ambientais que 
desgastam os hardwares. Quando um componente de hardware se desgasta, ele é substituído por uma 
peça de reposição. Para o software não existem peças de reposição. Toda falha em um software indica erro 
de projeto ou implementação. Portanto, a tarefa de manutenção de software é mais complicada que a 
manutenção de hardware. 
3. Software sob encomenda: A indústria de software tem caminhado cada vez mais para a construção de 
softwares com base em componentes, porém a maioria dos softwaresde Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Síntese da unidade
Os requisitos de software são muito importantes, pois definem as restrições do sistema e o que ele deve fazer. 
Os requisitos funcionais têm o papel de descrever o que o usuário deseja que o sistema tenha. Já os requisitos 
não funcionais descrevem não o que o sistema fará, mas como ele fará, como, por exemplo, desempenho, 
portabilidade e segurança. É muito importante documentar todos os requisitos extraídos das partes interessadas. 
Para se obter os requisitos dos clientes/usuários finais, existem várias técnicas, e o engenheiro de software deve 
escolher quais são as recomendadas para o tipo e tamanho de software que será desenvolvido.
44
Considerações finais
Esperamos que você tenha assimilado da melhor forma possível o 
conteúdo aqui apresentado. Para ampliar o seu conhecimento, consulte 
o aprofundamento de conteúdo e assista à videoaula da unidade, pois 
ambos contêm informações relevantes para seu aprendizado.
45
 4Unidade 4
4. Projeto de Interface 
Homem-Máquina 
Para iniciar seus estudos
Nesta unidade, você conseguirá compreender o conceito da interação 
homem-máquina (IHM) e as etapas de projetos de interface com 
usabilidade. A interface do usuário é o elemento mais importante de um 
software, pois, se a interface for mal projetada, poderá reduzir a capacidade 
de interação do usuário final e, consequentemente, ele poderá desistir de 
usar o sistema.
Objetivos de Aprendizagem
• Definir o conceito e os objetivos da interação homem-máquina 
(IHM).
• Explicar os objetivos da interação homem-máquina (IHM).
• Identificar o conceito e a importância da usabilidade.
• Identificar e explicar os princípios de usabilidade.
• Explicar o processo de análise, desenvolvimento e avaliação de 
projetos de interface de softwares.
• Esclarecer a importância do IHM para projetos de interface de 
softwares no desenvolvimento de softwares que possuam redução 
da carga de memória do usuário e que, principalmente, sejam 
fáceis de usar.
46
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
Introdução da unidade
Nesta unidade, serão apresentados os conceitos que permitirão ao aluno compreender a importância e os 
objetivos da interação homem-máquina (IHM). O sucesso de qualquer produto depende da aceitação pelo 
usuário, e isso está intrinsecamente ligado à facilidade de uso e à produtividade proporcionada pelo produto – 
características essas ligadas à interface do produto. Também nesta unidade serão demonstrados os princípios 
que norteiam um bom projeto de interface de software e que elevam a satisfação dos usuários.
4.1 Conceito de interface 
A interface é definida como o local onde o contato entre duas entidades ocorre. Por exemplo, a interface entre 
usuário e computador é o monitor (ROCHA; BARANAUSKAS, 2000). Já a ISO 9241-110 define interface como 
“todas as partes de um sistema interativo (de software ou hardware) que fornecem informações e controle 
necessários para que o usuário realize uma determinada tarefa com o sistema interativo”. Segundo Laurel (1993) 
apud Rocha e Baranauska (2000, p. 8), “interface é uma superfície de contato que reflete as propriedades físicas 
das partes que interagem, as funções a serem executadas e o balanço entre o poder e controle”.
O mundo possui outros exemplos de interfaces, como a maçaneta de uma porta, a direção de um carro, entre 
outros. O formato das interfaces reflete as qualidades físicas das partes na interação; por exemplo, a maçaneta 
de uma porta é projetada para se adequar ao formato da mão da pessoa que a utilizará, assim como o câmbio de 
um carro cuja localização sugere que será utilizado por uma pessoa destra (ROCHA; BARANAUSKA, 2000).
A interface tornou-se um importante conceito a ser explorado nos últimos anos. Essa evolução é atribuída à 
introdução ao computador LISA da Apple. LISA foi um dos primeiros computadores pessoais a usar uma interface 
gráfica e mouse. Quando se fala em interface homem-máquina, é bem provável que você pense em ícones, 
menus, barras de rolagem e pastas. Conforme vimos, interface não é apenas isso. 
Observando o nosso cotidiano, é possível perceber que, à medida que o hardware evoluiu, se fez possível a 
evolução da interface gráfica. Isso acabou ampliando o uso de computadores, notebooks e dispositivos móveis 
(smartphones, tablets e smartwatch) a qualquer tipo de pessoa/usuário.
Para saber mais informações sobre a evolução do hardware e da interface, assista ao filme 
Os Piratas do Vale do Silício (Pirates of Silicon Valley, em inglês), lançado em 1999 pela TNT, 
escrito e dirigido por Martyn Burke. O filme relata o surgimento das empresas Apple, de 
Steve Jobs, e Microsoft, de Bill Gates, e apresenta a rivalidade entre os proprietários dessas 
duas empresas. Também mostra o surgimento dos computadores pessoais, do MS-DOS e do 
primeiro computador a utilizar software com interface gráfica.
Saiba mais
 
47
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
4.1.1 Definição e objetivos da interface homem-máquina 
A interface homem-máquina (IHM) é também conhecida como interface homem-computador (IHC), termo que 
tem sido adotado desde meados dos anos de 1980. A IHM é definida por Rocha e Baranauskas (2000, p. 14) como 
“uma disciplina preocupada com o design, avaliação e implementação de sistema computacionais interativos 
para uso humano e com o estudo dos principais fenômenos ao redor deles”.
Os objetivos da IHM consistem em desenvolver softwares fáceis de usar (com usabilidade1), seguros e funcionais. 
De acordo com Nielsen (1993) apud Rocha e Baranauska (2000, p. 17), os objetivos elencados anteriormente 
podem ser englobados em um conceito mais amplo, denominado aceitabilidade de um sistema.
A Figura 14 apresenta os atributos da aceitabilidade de um sistema. São eles: aceitabilidade geral, social e prática.
Figura 14 – Atributos da aceitabilidade de um sistema
Fonte: ROCHA; BARANAUSKAS, 2000.
Segundo Rocha e Baranauska (2000), a aceitabilidade geral de um sistema consiste na combinação da 
aceitabilidade social com a aceitabilidade na prática. A aceitabilidade social refere-se à aceitação de um sistema 
quanto à sua relevância no seu papel social. No exemplo da porta giratória de uma agência bancária, o sistema 
foi projetado para impedir que assaltantes entrem com armas (armas de fogo, faca, canivetes). No entanto, esse 
sistema também impede a passagem de qualquer pessoa que esteja com algum tipo de metal, como chaves ou 
muitas moedas. Apesar de o benefício inicial da criação do sistema da porta giratória ser impedir assaltantes 
de entrarem com armas, ele não é aceito socialmente pelos usuários das agências bancárias, pois pode levar 
qualquer um a ser impedido diversas vezes – até retirar do corpo todos os objetos de metal – e, muitas vezes, não 
se sabe ao certo qual objeto estava impedindo a entrada (ROCHA; BARANAUSKA, 2000). 
A aceitabilidade prática refere-se aos parâmetros de custo, confiabilidade, compatibilidade com sistemas 
existentes, entre outros. Essa categoria é composta por uma subcategoria denominada usefulness (nesse contexto, 
1 De acordo com a Norma ISO 9241-11, a “usabilidade é a medida na qual um produto pode ser usado por usuários específicos para 
alcançar objetivos específicos com efetividade, eficiência e satisfação num contexto específico de uso”.
48
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
é traduzida como proveito). Usefulness consiste em poder utilizar um sistema para atingir determinado objetivo. 
Essa subcategoria pode ser dividida em outras duas: utilidade e usabilidade. Utilidade refere-se à verificação 
do propósito do sistema; por exemplo, verificar se um software educacional realmente auxilia o aprendizado. Já a 
usabilidade se refere à quão fácil é para o usuário usar as funcionalidades do sistema pretendido. 
Conclui-se que a IHM permite aos usuáriosde computadores executarem suas atividades com facilidade e 
segurança através de bom design (projeto/esbouço) dos softwares, sendo muito importante para o desenvolvimento 
de qualquer tipo de sistema. 
4.2 Análise e projeto de interfaces
O processo de análise e projeto de uma interface inicia-se pelo entendimento das tarefas necessárias para atender 
as funções e/ou necessidades dos usuários. Posteriormente, consideram-se as questões de projeto que serão 
aplicadas a todas as interfaces, utilizam-se ferramentas para criar protótipos das interfaces (essas ferramentas 
serão apresentadas na aula de aprofundamento) e, por fim, ocorre a implementação do projeto para ser avaliada 
a qualidade da interface pelos usuários finais. 
Segundo Pressman (2016), a análise e o projeto de interfaces contam com quatro modelos distintos para apoiar 
esse processo. São eles:
• Modelo de usuário: visa estabelecer o perfil dos usuários finais do sistema. Os usuários podem ser 
classificados como:
i. Novatos: trata-se de usuários que não possuem conhecimento pregresso do estilo e significado 
da interface.
ii. Usuários intermitentes e com conhecimento: trata-se de usuários que conhecem os termos 
da interface, mas ainda não têm incorporado o conhecimento para a execução das tarefas na 
aplicação.
iii. Usuários frequentes e com conhecimento: referem-se aos usuários que possuem o domínio 
completo da aplicação e que procuram atalhos e modos de interação abreviados. 
• Modelo de projeto ou modelo do designer: refere-se aos conceitos que o designer (projetista) ou 
engenheiro de software tem em sua mente sobre o sistema. É criado a partir das informações capturadas 
dos usuários. 
• Modelo mental do usuário: também é conhecido como percepção do sistema. Refere-se à imagem 
do sistema que os usuários finais possuem em suas mentes, ou seja, a imagem da estrutura de como 
a aplicação funciona de acordo com que o usuário final internalizou na sua memória. Já o modelo de 
usuário refere-se ao que o usuário desenvolve para entender e explicar a operação do sistema. 
• Modelo de implementação ou imagem do sistema: refere-se à imagem construída do sistema 
computacional em conjunto com livros, manuais, arquivos de ajuda, entre outras informações de apoio. A 
imagem do sistema é formada pelo layout (aparência física) e a forma como o sistema responde. É papel 
do designer garantir que a imagem do sistema seja fiel ao modelo conceitual, pois é através da imagem 
do sistema que o usuário elabora o seu modelo mental. Em geral, a satisfação do usuário ocorre quando 
o modelo de implementação e o modelo mental do usuário se assemelham.
49
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
A Figura 15 ilustra a relação entre os três modelos mentais: modelo do designer, modelo do usuário e imagem 
do sistema. 
Figura 15 – Três aspectos de modelos mentais
Fonte: Adaptação de ROCHA; BARANAUSKAS, 2000.
Pela figura anterior, é possível perceber que ocorre o estudo das necessidades do usuário pelo designer, que, por 
sua vez, construirá a imagem do sistema, ou seja, como o sistema deverá ser para atender as necessidades do 
usuário. Por meio da interação entre usuário e designer, será possível averiguar se a imagem do sistema – layout e 
a forma como o sistema responde – atendeu o modelo mental do usuário. 
4.2.1 Processo de projeto de interface
O processo de projeto de interfaces do usuário é iterativo; portanto, pode ser utilizado um modelo espiral 
existente nos métodos tradicionais. A Figura 16 apresenta o processo de análise e projeto de interfaces do usuário. 
Esse modelo possui quatro atividades: (i) análise e modelagem de interfaces, (ii) projeto de interfaces, (iii) 
construção de interfaces e (iv) validação de interfaces. 
Pela figura, percebe-se que o início do processo se dá pelo seu interior e que cada uma dessas atividades ocorrerá mais 
de uma vez. Cada volta em torno da espiral representa a elaboração adicional dos requisitos e do projeto resultante.
Figura 16 – Processo de projeto de interface do usuário
Fonte: PRESSMAN; MAXIM, 2016.
50
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
A atividade análise e modelagem de interfaces foca no perfil dos usuários que interagem com o sistema. Antes 
de os engenheiros de software se preocuparem com as questões técnicas, é necessário que eles entendam o 
que o usuário deseja. Conforme visto no tópico Análise e projetos de interfaces, o modelo mental do usuário 
é diferente do modelo que o projetista/desenvolvedor tem em mente. Diante desse impasse, faz-se necessário 
compreender bem o usuário antes de iniciar o desenvolvimento do projeto.
É nessa atividade que serão definidas as categorias de usuários através de registros do nível de habilidades, 
conhecimento da área e da aceitação do novo sistema. Em suma, trabalha-se para compreender a percepção do 
sistema para cada categoria de usuário. 
A atividade projeto de interface define um conjunto de objetos e ações de interface que permite ao usuário 
realizar todas as tarefas definidas para atender as metas de usabilidade do sistema. O ponto principal da 
engenharia de software é entender o problema antes de tentar desenvolver uma solução. Só assim será possível 
oferecer um sistema com qualidade. 
A construção da interface inicia-se com a elaboração de um protótipo que permite que cenários de casos 
de uso possam ser avaliados. Isso será discutido com mais detalhes no tópico Construção de interfaces com 
usabilidade.
Por último, a atividade de validação da interface concentra-se na verificação da capacidade da interface realizar 
corretamente todas as tarefas do usuário, no grau de facilidade de uso e aprendizado da interface e, por fim, na 
aceitação dos usuários. 
4.3 Padrões e questões de projeto de interface do usuário
Assim como no desenvolvimento de software surgiu a necessidade do uso de padrões do projeto para ajudar na 
solução de problemas recorrentes, no desenvolvimento das interfaces gráficas do usuário esse uso de padrões 
também se faz necessário. Um exemplo de um problema recorrente em projeto de interfaces é a situação em que 
um usuário deve inserir uma ou mais datas em um calendário. A solução mais simples para esse problema é usar 
um padrão de calendário contínuo e que rola, denominado por Laakso (2000) apud Pressman (2016, p. 334) de 
FaixaDeCalendário. Nesse modelo de calendário, a data atual aparece destacada e as datas futuras podem ser 
selecionadas através da rolagem e simbolizadas pelos caracteres “”, conforme ilustra a Figura 17.
Figura 17 – Exemplo do padrão de calendário contínuo
Fonte: SHUTTERSTOCK, 2018.
51
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
Para saber mais sobre padrões de projeto, leia o artigo Conheça os padrões de projeto, 
disponível no site Devmedia. E para mais informações sobre padrões de projeto de interface, 
pesquise na internet o artigo Padrões de projeto de interface de usuário – interface de 
usuário.
Saiba mais
À medida que aumenta o número de dispositivos móveis, faz-se necessário evoluir o projeto de interface do 
usuário. Essa evolução acarreta em quatro questões de projeto comumente empregadas: 
• Tempo de resposta – possui duas características: duração e variabilidade. Sobre a duração, a resposta 
do sistema não deve ser muito longa, pois acarretará em frustação e estresse por parte do usuário. A 
variabilidade refere-se ao distanciamento do tempo médio de resposta. No entanto, é preferível um 
tempo de resposta que varie 1 segundo a um comando que possui um tempo de resposta que varie na 
escala de 0,1 a 2,5 segundos.
• Recursos de ajuda – esse recurso deve ser acessado sempre que solicitado pelo usuário e sem ele ter a 
necessidade de abandonar a interface.
• Tratamento de erros – toda mensagem de erro ou alertas direcionadas aos usuários devem apresentar 
as seguintes características: (i) o problema deve ser descrito em uma linguagem que ousuário consiga 
compreender; (ii) indicar como o usuário fará para solucionar o erro; (iii) indicar as consequências 
negativas que o erro poderá acarretar, como “arquivos poderão ter sido corrompidos ou perdidos” (esse 
alerta permitirá ao usuário verificar se algo ocorreu ou não); e (iv) nunca colocar a culpa no usuário. 
• Atribuição de nomes a comandos e menus – o uso de comandos digitados era o meio mais comum de 
interação entre usuários e software. Atualmente, com a disponibilidade de interfaces orientadas a janelas, 
reduziu-se o uso de comandos, pois hoje é possível clicar e tocar nas telas/ícones. Somente usuários 
com mais conhecimento ainda preferem utilizar comandos – como CTRL+P para imprimir um arquivo – a 
interagir com interfaces.
Para saber mais sobre as diretrizes para o desenvolvimento de aplicações web com 
acessibilidade, acesse o site que contenha o título Cartilha Acessibilidade na Web W3C 
Brasil.
Saiba mais
52
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
4.4 Construção de interfaces com usabilidade 
Existem diversas interfaces de usuário, projetadas para softwares tradicionais, aplicações para web (Web App2 ), 
dispositivos móveis ou simplesmente para um produto de consumo (por exemplo: o câmbio do automóvel que 
é projetado apenas para pessoas destras). É notável que existem diferenças importantes entre as interfaces dos 
softwares explicitados anteriormente. A maior diferença existe devido às restrições físicas impostas por pequenos 
dispositivos móveis (por exemplo, smartphone e tablets). Devido a esse fator, o projetista de interfaces móveis deve 
compactar a interação do usuário. No entanto, todas essas interfaces devem possuir os princípios de usabilidade, 
conforme apresentado no tópico Princípios fundamentais para o desenvolvimento de interfaces.
De acordo com Dix (1999) apud Pressman (2016, p. 341), as interfaces para aplicações web e para dispositivos 
móveis devem responder a três perguntas: (i) “Onde estou?”; (ii) “O que posso fazer agora?” e (iii) “Onde eu 
estive e onde posso ir?”. Se o usuário conseguir responder a todas essas perguntas, significa que ele entendeu o 
contexto e consegue navegar de forma mais eficiente pela aplicação ou pelo aplicativo.
4.4.1 Princípios fundamentais para o desenvolvimento de interfaces 
Existe um grande número de web apps e aplicativos móveis. Para evitar a concorrência, a interface para o usuário 
deve ser atraente, pois uma interface malfeita desapontará o usuário – o que poderá implicar na desistência do 
uso e fazê-lo procurar outra opção. 
Diante disso, Bruce Tognozzi (2001) apud Pressman (2016, p. 338) estabeleceu um conjunto de princípios de 
projeto fundamentais que foram adaptados por Pressman (2016) para contemplar as restrições físicas impostas 
pelos dispositivos móveis e, consequentemente, gerir uma melhor usabilidade. Alguns desses princípios são: 
• Antecipação – a aplicação deve ser desenvolvida para prever o próximo passo do usuário. Por exemplo, 
suponha que o usuário esteja pesquisando sobre um drive de uma impressora para o Windows 10. O 
projetista deve antecipar que o usuário pode desejar realizar o download do drive e disponibilizar um link 
que permita a realização dessa ação.
• Comunicação – a interface deve comunicar com o usuário. A comunicação pode ser feita via texto ou 
imagem. Por exemplo, se o usuário enviou um documento para a impressão, uma mensagem de texto 
deverá ser exibida ou, então, uma imagem de um papel se deslocando para a impressora. 
• Consistência – o uso de controles de navegação, menus e ícones deverá ser coerente. Por exemplo, se 
um aplicativo para dispositivo móvel possui um conjunto de três ícones (ex.: Início, Voltar e Sair), e esses 
ícones são considerados importantes para representar funções, então devem aparecer em todas as telas. 
Eles não poderão ser movidos para outros cantos de acordo com a mudança das telas. Portanto, esse tipo 
de ícone deve ser utilizado para representar funções importantes e possuir um significado ostensivo no 
contexto do aplicativo. 
• Autonomia controlada – a interface deve facilitar a navegabilidade do usuário, e este, por sua vez, deve 
respeitar as regras estabelecidas para a aplicação. Por exemplo, se a navegação exigir acesso controlado 
(senha e login) ao(s) conteúdo(s), não deve existir nenhuma forma que permita ao usuário ludibriar esse 
controle imposto pelo projetista. 
2 Trata-se de um site mobile, ou seja, um site que assume o comportamento de aplicativo.
53
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
• Eficiência – o projeto de uma aplicação e de sua interface deve otimizar o trabalho dos usuários. Esse 
princípio refere-se à eficiência alcançada por usuários experientes após certo tempo de uso do sistema. 
Para tal, é preciso que o sistema seja eficiente no uso, ou seja, de forma que, uma vez que o usuário tenha 
aprendido a utilizá-lo, consiga ter um alto nível de produtividade.
• Flexibilidade – a interface deve ser flexível a fim de permitir que usuários consigam realizar suas tarefas 
diretamente e outros consigam explorá-la para atingir tal objetivo. Portanto, a interface deve sempre 
permitir ao usuário saber onde ele está e desfazer ações (por exemplo, retornar à tela anterior).
• Foco – a interface, juntamente com o seu conteúdo, deve permanecer na(s) tarefa(s) do usuário. Esse 
princípio é muito importante, principalmente no contexto de aplicativos para dispositivos móveis, onde 
os usuários tendem a querer fazer coisas demais, o que pode ocasionar lentidão.
• Redução da latência – não faça o usuário esperar que alguma operação interna seja concluída (baixar 
uma imagem, por exemplo) para permitir que ele consiga usar outras aplicações ou continuar em suas 
tarefas. 
• Facilidade de aprendizagem – a interface da aplicação deve ser projetada para minimizar o tempo 
de aprendizagem do usuário; além disso, deve ser fácil de memorizar, pois, após um tempo, quando o 
usuário resolver reutilizá-la, ele não deverá reaprendê-la. Sendo assim, a interface deverá ser um projeto 
simples e intuitivo, que organiza o conteúdo e funcionalidades em categorias explícitas para o usuário.
• Legibilidade – a interface deverá apresentar conteúdo legíveis a todos os usuários, sejam eles jovens ou 
idosos. Para alcançar esse princípio, o projetista de interfaces deverá priorizar o uso de estilos de tipos 
e tamanhos de fontes que possam ser modificáveis pelos usuários. Os projetistas deverão usar fundos 
coloridos para aumentar o contraste.
• Acompanhar o estado da interação – deverá ser permitido ao usuário sair da aplicação e retornar do 
ponto onde parou. Geralmente, utiliza-se de cookies3 para armazenar as informações de estado.
Nielsen e Wagner (1996) apud Pressman (2016, p. 339) propuseram uma lista do que não se deve fazer em projetos 
de interfaces, sendo um ótimo complemento aos princípios elencados anteriormente:
• Não force o usuário a ler muitos textos, principalmente quando for para explicar uma operação ou auxiliar 
na navegação.
• Não obrigue o usuário a descer até o fim da página. 
• Não permita que a estética exceda a funcionalidade da aplicação. 
• Não obrigue o usuário a procurar na tela como acessar links que o direcionem a outros conteúdos ou 
serviços.
Por fim, uma interface deverá ser bem projetada para aumentar a percepção do usuário ao conteúdo e/ou serviços 
oferecidos. Ela não precisará ter um layout chamativo, mas precisará estar bem estruturada e fácil de utilizar. 
3 Trata-se de um pedaço de um texto que um servidor web armazena no HD (hard disk) do usuário. Atualmente, os cookies são muito 
usados para armazenar informações sobre os visitantes dos sites.
54
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
4.4.2 Fluxo de trabalho de projeto de interface para web apps e dispositivos 
móveis
As informações coletadas através dos requisitos do usuário são importantes para a criação do layoutda tela, onde 
serão definidos o posicionamento de ícones, a especificação de texto e título para as telas, a especificação de 
itens de menus principais e secundários, entre outros. Para criar layouts das telas ou protótipos de telas, podemos 
utilizar ferramentas para implementar os protótipos de interfaces, simulando a combinação de cores, tamanho 
dos ícones ou menus, etc. Pressman (2016) define algumas tarefas básicas para representar um fluxo de trabalho 
de projeto de interface: 
1. É importante revisar as informações contidas no documento de requisitos do usuário e aperfeiçoá-lo 
conforme a necessidade.
2. É importante desenvolver um protótipo das telas do web apps e/ou dispositivos móveis. 
3. É importante mapear os objetivos do usuário em ações de forma que se permita responder à seguinte 
pergunta: “Como a interface permitirá ao usuário alcançar os seus objetivos?”. 
4. É importante definir um conjunto de tarefas do usuário que devem estar associadas a cada ação. Durante 
o projeto, os requisitos devem contemplar as interações específicas – como comprar um livro – que 
abrangem problemas de navegação (dificuldade para acessar determinada tela), conteúdo dos ícones e 
funções da aplicação.
5. É importante criar uma sequência de imagens de storyboard (imagens de tela) para cada ação de interface 
para assim representar como a interface responde à interação do usuário, identificando os links de 
navegação e objetos que serão acessados. 
É importante frisar que esse conjunto de tarefas deve ser escolhido e adaptado de acordo com a aplicação que será 
desenvolvida. A lista de tarefas completas é encontrada no livro Engenharia de Software – Uma Abordagem 
Profissional (PRESSMAN; MAXIM, 2016, p. 341-342).
4.4.3 Avaliação do projeto de interface
A avaliação de um projeto de interface se dá após a criação de um protótipo da(s) tela(s), conforme indicado na 
Figura 18. Existem duas formas de realizar essa avaliação, sendo que, em ambas, ocorre uma solicitação ao usuário 
para testar o protótipo de interface navegável4. Na primeira forma, será solicitado ao usuário que expresse seus 
pensamentos à medida que está navegando, o que permite ao projetista coletar o feedback imediato do usuário 
em relação à eficácia da interface.
A segunda forma consiste em aplicar métodos estatísticos (por exemplo, questionários, formulários de avaliação) 
para avaliar a interface. Através desses dados, é possível extrair informações como: “80% de todos os usuários 
não gostam da forma que é utilizada para salvar os arquivos”.
Com base nas informações coletadas em qualquer uma dessas duas formas, são feitas as modificações no 
protótipo. O ciclo de avaliação dos protótipos da interface é contínuo até que nenhuma modificação adicional 
seja necessária. 
4 Consiste em um esboço da tela/página, porém onde o usuário consegue acessar menus, links e etc.
55
Engenharia de Software | Unidade 4 - Projeto de Interface Homem-Máquina 
Figura 18 – Exemplo de um protótipo de tela para dispositivo móvel
Fonte: SHUTTERSTOCK, 2018.
Para uma discussão completa sobre métodos de avaliação de interfaces do usuário, consulte: 
STONE, D. et al. User interface design and evalution. Massachusetts, EUA: Morgan Kaufman, 
2005.
Saiba mais
Síntese da unidade
A interface é conceituada como o local onde o contato entre duas entidades ocorre. Por exemplo, a interface 
entre usuário e computador é o monitor. A interface homem-máquina (IHM) é também conhecida como 
interface homem-computador (IHC). A IHM é definida como uma disciplina preocupada com o projeto, avaliação 
e implementação de softwares para uso humano. Portanto, a IHM permite aos usuários de computadores 
executarem suas atividades com facilidade e segurança através de um bom design dos sistemas. A usabilidade é 
um conceito implícito à IHM, que, por sua vez, possui alguns princípios que permitem definir e medir o quanto a 
interface do sistema é agradável para os usuários finais. Foi apresentado o processo de projeto de interface que 
se utiliza da mesma ideia do modelo espiral do modelo de processo de software tradicional. Finalmente, foram 
apresentadas as etapas do projeto de interfaces com usabilidade.
56
Considerações finais
Esperamos que você tenha conseguido assimilar da melhor forma possível 
o conteúdo aqui apresentado. Para ampliar o seu conhecimento, consulte 
o aprofundamento de conteúdo e assista à videoaula da unidade, pois 
ambos contêm informações relevantes para seu aprendizado.
57
Referências
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9241: 
ergonomia da interação humano-sistema. Parte 100: introdução às 
normas relacionadas à ergonomia de software. Rio de Janeiro: ABNT, 2012.
MERCADO de PCs marca quinto ano consecutivo de declínio em vendas. 
SOS – Serviço Online de Segurança, 06 mar. 2017. Disponível em: 
 Acesso em: 23 jun. 2018.
PEREIRA, Juliana A.; FIGUEIREDO, Eduardo. Configuração de produtos 
em linha de produtos de software. Disponível em: . 
Acesso em: 23 jun. 2018.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma 
abordagem profissional. 8. ed. Porto Alegre: AMGH Editora, 2011.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma 
abordagem profissional. 8. ed. Porto Alegre: AMGH Editora, 2016. 968p. 
ISBN 9788580555332.
ROCHA, Heloísa; BARANAUSKAS, Cecília. Design e avaliação de 
interfaces humano-computador. Campinas, SP: NIED/UNICAMP, 2000. 
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. Editora Pearson, 
2011. 
	Unidade 1
	1. Introdução à Engenharia de Software
	Unidade 2
	2. Modelos do Ciclo de Vida do Software
	Unidade 3
	3. Engenharia de Requisitos e Modelagem de Software 
	Unidade 4
	4. Projeto de Interface Homem-Máquinacontinua a ser construída de forma 
personalizada (sob encomenda). Um componente de software2 deve ser projetado e implementado para 
ser reutilizado em muitos programas diferentes. São exemplos de componentes de software Java para 
interface: RichFaces, PrimeFaces, OpenFaces e IceFaces.
2 Para mais informações sobre componentes de software acesse o site: https://pt.wikipedia.org/wiki/
Engenharia_de_software_baseada_em_componentes.
https://pt.wikipedia.org/wiki/Engenharia_de_software_baseada_em_componentes
https://pt.wikipedia.org/wiki/Engenharia_de_software_baseada_em_componentes
10
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
1.4 Campos de aplicação de software
Segundo Pressman (2016), atualmente existem sete grandes categorias de software, que apresentamos a seguir:
1. Software Básico: Conjunto de programas feito para atender a outros programas, como: compiladores 
(Ex: GCC), editores (Ex: Word, WordPad) e utilitários para gerenciamento de arquivos (Ex: Windows Explorer 
do Windows). 
2. Software de Aplicação/Comercial: Trata-se de programas sob medida que solucionam uma necessidade 
específica de negócio, como: facilitar operações comerciais ou tomadas de decisões administrativas/
técnicas (Ex: Portal de Compras – este software foi desenvolvido para realizar licitações do estado de Minas 
Gerais). 
3. Software Científico/de Engenharia: Caracteriza-se por algoritmos “number crusching” – algoritmos para 
processamento numérico pesado – utilizados pela astronomia (Ex: Astro), biologia molecular (Ex: Protean 
3D) e aerodinâmica (Ex: C.A.S.A. (Cálculo automático de sistemas aerodinâmicos)). 
4. Software Embutido/Embarcado: É um tipo de software que é residente em um produto ou sistema e 
utilizado para implementar e controlar características e funções para o usuário final e para o próprio 
sistema. Este tipo de software executa funções limitadas e específicas (por exemplo, controle do painel 
do micro-ondas) ou fornece função significativa e capacidade de controle (por exemplo, computador de 
bordo de um carro). 
5. Software para Computadores Pessoais: Projetado para prover capacidade específica de utilização por 
muitos clientes diferentes. Focado em um mercado limitado e particularizado, como: processamento 
de texto (Ex: Word, WordPad), planilha eletrônica (Ex: Excel), computação gráfica (Ex: Adobe Photoshop), 
entretenimento (Ex: jogos - Paciência) e multimídia (Ex: RealPlayer e Windows Media Player). 
6. Aplicações para a Web: É caracterizado por aplicações centralizadas em rede, como aplicativos e softwares 
baseados em navegadores (browsers). Como por exemplo podemos citar os sites de e-commerce.
7. Software de Inteligência Artificial: Faz o uso de algoritmos para solucionar problemas complexos que 
não são passíveis de computação ou de análise direta, como por exemplo: robótica, reconhecimento 
de padrões (de imagem e de voz), redes neurais artificiais, provas de teoremas e jogos. Como exempo 
deste tipo de software temos o programa A.L.I.C.E. (Artificial Linguistic Internet Computer Entity, ou Entidade 
Computadorizada de Linguagem Artificial para Internet)3.
Diversos engenheiros de software em todo mundo trabalham em projetos de software de uma ou mais dessas 
categorias. Em alguns casos, novos sistemas estão sendo construídos, mas em muitos outros sistemas já 
existentes estão sendo corrigidos, adaptados e/ou evoluídos. 
1.4.1 Software Legado
Software legado é definido como software antigo, ou seja, que foi desenvolvido há muitos anos. Esse tipo de 
software tem tido atenção desde os anos 1960. De acordo com Dayani-Fard et al (1999) apud Pressman (2016, p.8), 
softwares legados foram desenvolvidos décadas atrás e têm sido continuamente modificados para se adequar a 
mudanças dos requisitos de negócio e a plataformas computacionais. Empresas consideram que é dispendioso 
manter esses softwares e arriscado evoluí-los (Dayani-Fard et al. apud Pressman, 2016, p.8).
3 Para mais informações acesse o site: https://pt.wikipedia.org/wiki/A.L.I.C.E.
https://pt.wikipedia.org/wiki/A.L.I.C.E
11
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
Já para Liu et (1998) apud Pressman (2016, p.8) “muitos sistemas legados permanecem dando suporte para 
funções de negócios vitais e são indispensáveis para o mesmo”. 
 
Conclui-se que um software legado é caracterizado por um tempo de vida longo e por ser 
crítico na área dos negócios.
Softwares legados são um desafio para a engenharia de software, pois há projetos que não são 
expansíveis, código intrincado (de difícil compreensão), documentação pobre ou inexistente 
entre outros. Tudo isso caracteriza um software de baixa qualidade, difícil de ser evoluído ou 
simplesmente de dar manutenção. 
Diante dos pontos já expostos, a engenharia de software recomenda que softwares legados 
só passem por evolução/manutenção se for vital para o seu funcionamento (Sommerville, 
2011). Um exemplo de que não é interessante realizar manutenção desnecessária em 
softwares antigos é um fato ocorrido em 1999 – o Bug do Milênio. 
Este possível bug levou programadores do mundo inteiro a realizarem manutenção nos 
sistemas, pois antigamente a data era salva no padrão de 2 dígitos (como, por exemplo, 99) para 
economizar memória. Acreditava-se que se não alterassem a data para o padrão de 4 dígitos 
na virada do ano 2000, diversos sistemas deixariam de funcionar acarretando incontáveis 
erros. O resultado foi um investimento financeiro alto para realizar essa manutenção, mas no 
final das contas ocorreram poucas falhas decorrentes do bug do milênio.
Fique atento!
Para saber mais sobre software legado, assista ao vídeo Você sabe o que é SOFTWARE 
LEGADO?, do Canal TI, no Youtube.
E para mais informações sobre o bug do milênio, assista ao vídeo A história do bug do 
milênio, da TecMundo, no Youtube. 
Saiba mais
12
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
1.4.2 Aplicações mobile e computação na nuvem
Figura 1 – Computação em nuvem (cloud)
Fonte: SHUTTERSTOCK, 2018.
A grande quantidade de dispositivos móveis criou um novo mercado de desenvolvimento de software com 
características próprias. Este tipo de software que está em crescimento é geralmente designado apenas pelo termo 
app (aplicativos). Esses aplicativos são desenvolvidos para plataformas mobile como iOS, Android ou Windows Mobile. 
Atualmente existem mais dispositivos móveis do que computadores tradicionais (Ex: notebooks e computadores 
pessoais) (UOL, 2017). Tais dispositivos trazem uma série de desafios e possibilidades para o desenvolvimento do 
software, como limitações de recursos (memória, processamento, bateria, tamanho de telas e entrada de dados) e 
também possuem recursos de hardware até então pouco comuns, como bússola, acelerômetro, GPS dentre outros. 
Leia, no site da revista Exame, a notícia Dispositivos móveis deverão ocupar o mercado do 
PC. 
A computação em nuvem possui uma infraestrutura que permite a qualquer usuário, 
independentemente do lugar em que está, usar algum dispositivo (smartphone, notebook) para 
visualizar, modificar seus dados armazenados em um servidor online, também conhecido 
como servidor na nuvem (Por exemplo Dropbox e Office 365). 
A computação em nuvem é definida como a utilização da capacidade de memória, 
armazenamento e processamento de servidores interligados pela internet. Já Mobile refere-se 
execução de softwares aplicativos em dispositivos portáteis como smartphone e tablet. 
Saiba mais
13
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
Para saber mais sobre Computação na Nuvem, assista ao vídeo Você sabe o que é Cloud 
Computing, ou Computação na Nuvem?, da CanalTech, no Youtube.
Saiba mais
1.4.3 Linhas de produtos de software
A abordagem Linhas de Produtos de Software (LPS) ou Software Product Lines (SPL) é definida como o uso de técnicas 
de engenharia que permitem criar um grupo de softwares similares a partirde um conjunto de características 
comuns a todos esses sistemas. Em resumo, é um método que permite a aplicação da técnica de reúso de software 
(reaproveitamento de código já desenvolvido e testado). 
O desenvolvimento de softwares utilizando a técnica de LPS está cada vez mais crescente. Como essa técnica 
permite agrupar componentes de software comuns e que já foram desenvolvidos (prontos), consequentemente 
teremos um desenvolvimento mais ágil de sistemas. 
Vale ressaltar que para atender as necessidades dos usuários e o contínuo processo de automação dos meios 
produtivos, os softwares têm se tornado cada vez maiores e complexos, o que implicaria em um processo de 
desenvolvimento mais demorado se comparado com o uso da técnica LPS que utiliza o reúso de componentes 
já prontos. 
Para mais informações, leia o artigo Linha de Produtos de Software: Conceitos e 
Ferramentas, de Juliana Alves Pereira, Eduardo Figueiredo e Heitor Augustus Costa, 
disponível na Internet.
Saiba mais
1.5 Engenharia de software
Engenharia de software é uma disciplina cujo o foco está em todos os aspectos da produção de software – desde 
a especificação do sistema até a sua manutenção.
Para Bauer (1969) apud Pressman (2016), a engenharia de software é “a criação e a utilização de sólidos princípios 
de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em 
máquinas reais”. 
14
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
Já para IEEE (1999) apud Pressman (2016), a engenharia de software é “a aplicação de uma abordagem sistemática, 
disciplinada e quantificável, para o desenvolvimento, operação e manutenção do software; isto é, a aplicação de 
engenharia ao software”.
A vantagem de se usar as técnicas de engenharia de software está em obter software com qualidade, dentro do 
cronograma e dentro do orçamento planejado inicialmente.
A abordagem adotada para se obter software com qualidade é denominada processo de software, que veremos 
mais detalhadamente na unidade 2.
A base para engenharia de software é definida por Pressman (2016) como uma tecnologia em camadas, conforme 
a figura 2. 
Esta figura apresenta quatro camadas:
(i) Foco na qualidade.
(ii) Processo.
(iii) Métodos.
(iv) Ferramentas. 
Figura 2 – Conceito de ética na engenharia de software 
Ferramentas
Métodos
Processo
Foco na qualidade
Fonte: PRESSMAN; MAXIM, 2011, p. 39.
A base de sustentação da engenharia de software é o foco na qualidade, por isso aparece como a base da figura 
que se assemelha a uma pirâmide. 
Posteriormente, temos a camada de processo, responsável por definir uma metodologia que permitirá o 
desenvolvimento do software com qualidade e entrega dentro do prazo. Portanto, a camada de processo é a 
base para o controle do gerenciamento de projetos de software, onde a qualidade é garantida, e as mudanças 
(evoluções e/ou manutenções) do software são geridas de forma apropriada. 
Em seguida, temos a camada métodos; estes fornecem as informações técnicas para desenvolver o software, tais 
como: comunicação, análise de requisitos, modelagem de projeto, construção de programa, testes e suporte. 
15
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
Por último, temos a camada ferramentas. Estas fornecem suporte automatizado ou semiautomatizado para o 
processo e para os métodos. Como por exemplo as ferramentas CASE (Computer Aided Software Engineering). 
1.6 Ética na engenharia de software
Figura 3 – Conceito de ética na engenharia de software 
Fonte: SHUTTERSTOCK, 2018.
Diversos profissionais, como advogados e médicos, possuem um código de ética, ou seja, regras que regulam a 
liberdade das pessoas que trabalham na área. O mesmo ocorre com os profissionais de TI implicitamente – os 
engenheiros de software. O profissional de engenharia de software deve aceitar que seu trabalho envolve grandes 
responsabilidades – além de simplesmente aplicar técnicas (programar).
Nenhum profissional de TI deve usar seu conhecimento de forma ilegal ou que que atente contra a moralidade. 
Existem áreas nas quais os padrões de comportamento não são ilegais, mas são imorais. Segundo Sommerville 
(2011, p.9), são elas:
1. Confidencialidade: deve-se respeitar a confidencialidade das informações de seus empregados ou 
clientes, independentemente de ter sido assinado um acordo formal de confidencialidade. 
16
Engenharia de Software | Unidade 1 - Introdução à Engenharia de Software
2. Competência: não aceitar um trabalho acima do seu nível de competência.
3. Direitos de propriedade intelectual: deve-se ter conhecimento das leis do país a respeito da propriedade 
intelectual, como patentes e copyright.
4. Mau uso do computador: não fazer mau uso de seus conhecimentos técnicos a outras pessoas, como 
disseminar vírus ou outros malwares pela rede. 
Leia o Código de Ética e de Prática Profissional da Engenharia de Software e o Código 
de Ética publicado pela Sociedade Brasileira de Computação (SBC), ambos disponíveis 
na Internet.
Saiba mais
Síntese da unidade
Nesta unidade você aprendeu sobre os conceitos fundamentais para o desenvolvimento da disciplina Engenharia 
de Software:
• O que é software.
• Qual a diferença de software de produto e software de serviço.
• Quais as características que um software deve ter.
• Quais os tipos de softwares existentes e quais estão sendo mais utilizados atualmente.
• O que é software legado.
• Qual a importância da engenharia de software.
• Qual a importância da ética para os profissionais da tecnologia da informação no desenvolvimento de 
softwares.
17
Considerações finais
Esperamos que você tenha conseguido assimilar da melhor forma possível 
o conteúdo aqui apresentado. Para ampliar o seu conhecimento, consulte 
o aprofundamento de conteúdo e assista à videoaula da unidade, pois 
contêm informações relevantes para seu aprendizado.
18
 2Unidade 2
2. Modelos do Ciclo de Vida do 
Software
Para iniciar seus estudos
Olá! Nesta unidade, iniciaremos os estudos sobre os modelos de ciclo 
de vida do software, também conhecido como processo de software. 
Apresentaremos uma metodologia para a prática da criação de um 
software trabalhando os seguintes conceitos:
• O que é processo de software.
• O que é modelo de processo de software e quais são os principais 
modelos.
• O que é o modelo de processo unificado e quais são as suas fases.
• O modelo de processo pessoal (PSP).
Objetivos de Aprendizagem
• Explicar o conceito de processo de software.
• Diferencie os tipos de modelos de processos de software existentes 
na literatura.
• Identificar e discuta a importância da utilização do processo de 
softwares tradicionais no desenvolvimento de softwares.
• Identificar quando aplicar um processo tradicional, um processo 
unificado e/ou Processo Pessoal (PSP).
19
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
Introdução da unidade
Nesta unidade, apresentaremos conceitos que possibilitarão ao aluno entender a importância da utilização dos 
modelos de processos de software existentes na engenharia de software para desenvolver softwares com qualidade 
e dentro do planejamento inicial. 
2.1 O Processo de software
Processo é um conjunto sequencial e particular de ações com objetivo comum. Um processo não é uma descrição 
rígida de como desenvolver um software, e sim uma abordagem adaptável que possibilita à equipe de software 
selecionar e escolher qual o conjunto adequado às ações e tarefas. O objetivo é entregar o software dentro do 
cronograma (cumprir o prazo) e com boa qualidade (PRESSMAN; MAXIM, 2016).
Processo de software é também conhecido como modelo do ciclo de vida de um software, porém aqui adotaremos 
a terminologia mais utilizada na literatura, que é processo de software. Processo de software é um conjunto 
estruturado de atividades necessárias para desenvolver um sistema de software, representado esquematicamente 
na figura4. 
A figura ilustra que cada atividade é composta por um conjunto de ações; cada ação é definida por um conjunto 
de tarefas que identifica:
• as tarefas de trabalho a serem completadas.
• os artefatos de software que serão produzidos.
• os fatores de garantia da qualidade que serão exigidos.
• os marcos utilizados para indicar progresso.
20
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
Figura 4 – Uma metodologia do processo de software
Fonte: PRESSMAN; MAXIM, 2016.
Segundo Sommerville (2011), o modelo de processo de software tem a finalidade de auxiliar na criação de um 
software com alta qualidade e dentro do prazo estabelecido. Existem vários processos de software distintos; nesse 
contexto, Pressman e Maxim (2016) afirmam que cinco atividades devem ser incluídas como fundamentais para 
a engenharia de software.
• Comunicação: a comunicação é importante para que se entenda quais são os objetivos dos stakeholders 
(partes interessadas). Por meio da comunicação, será possível entender e definir as necessidades, funções 
e características do software.
• Planejamento: essa atividade consiste em criar um plano de projeto do software. Nesse plano, deve 
constar o trabalho que o engenheiro de software deverá desempenhar, como descrever as tarefas técnicas 
a serem desenvolvidas, os possíveis riscos do projeto, os recursos necessários, as funcionalidades que 
serão produzidas e um cronograma de trabalho.
• Modelagem: consiste em criar modelos para facilitar o entendimento da equipe de desenvolvimento em 
relação às necessidades e objetivos do software solicitado pelos stakeholders.
• Construção: essa atividade refere-se ao desenvolvimento (geração de código) do software e também à 
realização de testes para verificar/encontrar erros de codificação.
21
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
• Entrega: nessa atividade, é feita a entrega parcial ou integral do software ao cliente. Este avaliará o software 
entregue e fornecerá um feedback à equipe de desenvolvimento. 
Essas cinco atividades podem ser utilizadas para o desenvolvimento tanto de programas pequenos e simples 
quanto de programas grandes e complexos. A diferenças estará nos detalhes e na complexidade dos processos.
2.2 Modelos de processo
Esses modelos foram propostos para trazer ordem ao caos existente na área de desenvolvimento de software 
(PRESSMAN; MAXIM, 2016). Segundo Sommerville (2011), modelo de processo de software é definido como 
uma representação simplificada de um processo de software, em que cada modelo representa uma perspectiva 
particular de um processo, fornecendo informações parciais sobre ele. Os modelos de processo de software 
que veremos nesta unidade são: modelo cascata, modelo de processo incremental e modelo de processo 
evolucionário.
Para saber mais sobre processos de software e modelos de processos de software, leia o artigo 
disponível em: . Acesso em: 30 jun. 2018.
Saiba mais
2.2.1 Modelo cascata
Foi o primeiro modelo de processo de desenvolvimento de software a ser proposto. Esse modelo é também 
conhecido como ciclo de vida clássico. Ele sugere que o desenvolvimento do software seja feito sequencialmente 
e disciplinado (PRESSMAN; MAXIM, 2016). Esse modelo possui cinco fases: comunicação, planejamento, 
modelagem, construção e emprego, conforme ilustrado na figura 5.
Figura 5 – Modelo cascata
Comunicação
início do projeto
levantamento
de necessidades
Plenejamento
estimativas
cronograma
acompanhamento
Modelagem
análise
projeto
Construção
condi�cação
testes
Emprego
entrega
suporte
feedback
Fonte: PRESSMAN; MAXIM, 2016.
https://medium.com/omarelgabrys-blog/software-engineering-software-process-and-software-process-models-part-2-4a9d06213fdc
https://medium.com/omarelgabrys-blog/software-engineering-software-process-and-software-process-models-part-2-4a9d06213fdc
22
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
Nas últimas três décadas, o modelo cascata tem recebido diversas críticas relativas à sua eficácia. Os problemas 
apontados são: 
• É difícil para o cliente apresentar aos engenheiros de softwares todas as suas necessidades. A divisão 
nessas cinco fases distintas torna difícil atender às necessidades de mudanças nos requisitos do cliente. 
Portanto, esse modelo só é recomendado utilizar no desenvolvimento de software quando os requisitos 
são bem definidos pelos clientes. Se ocorrer mudanças durante o processo de desenvolvimento, elas 
devem ser bem pequenas.
• O sistema só é implantado no final do desenvolvimento do projeto. Erros graves, se não detectados 
durante o desenvolvimento, podem ser desastrosos.
Conclui-se que o principal problema do modelo cascata é o impedimento de inserir alterações de requisitos 
depois que esse modelo de processo já foi iniciado. Devido ao fato da utilização da abordagem sequencial (em 
que uma fase precisa ser completada antes de iniciar a próxima fase). Portanto, esse modelo é recomendado 
apenas para softwares cujos requisitos estão bem definidos. 
2.2.2 Modelo de processo incremental
Diferente do modelo cascata, cuja entrega é feita somente após concluir todas as cinco fases, o modelo 
incremental consiste em implementar uma parte (também chamando de incremento) do software e entregar aos 
usuários/clientes para que deem um feedback (retorno, comentário) aos desenvolvedores do software. Os feedbacks 
permitem os desenvolvedores criarem outras versões do software até que esteja adequada ao usuário/cliente 
(PRESSMAN; MAXIM, 2016). A figura 6 ilustra as fases do modelo incremental para aplicar a cada incremento ou, 
então, a cada quantidade de incrementos que se fizerem necessários para o desenvolvimento do software. 
Figura 6 – Modelo incremental
Incremento 1 Incremento 2 Incremento N
Comunicação
Planejamento
Implantação
...
Comunicação
Planejamento
Implantação
...
...
Comunicação
Planejamento
Implantação
...
Fonte: SOUZA, [200-?].
23
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
O modelo incremental ilustra a forma como nós resolvemos os problemas. Geralmente, nós não pensamos em 
uma solução completa para determinado problema. A solução é produzida aos poucos, corrigindo e avançando 
à medida que obtemos sucesso. 
As vantagens do modelo incremental são: 
(i) O custo de inserir mudanças nos requisitos do cliente é reduzido.
(ii) Como as entregas são feitas por partes (incrementos), torna mais fácil obter feedback dos clientes 
sobre o software.
(iii) Permite aos clientes uma melhor forma de acompanhar o quanto já foi implementado do software 
durante reuniões de entregas incrementais.
(iv) A entrega feita por incrementos permite uma utilização mais rápida por parte do cliente que não usa 
necessariamente todas as funcionalidades.
As desvantagens do modelo incremental são: 
(i) a inserção de mudanças no código posterior a cada entrega de incrementos torna o processo de 
software mais difícil e caro.
(ii) desenvolvedores que estão acostumados a trabalhar com modelos sequenciais (como o modelo 
cascata) podem ter problemas quando trabalham com o modelo incremental, que é mais flexível. 
2.2.3 Modelo de processo evolucionário
Modelos evolucionários são iterativos. É modelo de processo no qual o software é projetado para evoluir ao longo 
do tempo, por isso possibilita o desenvolvimento de versões cada vez mais completas do software. A seguir, veja 
dois modelos comuns em processos evolucionários.
Prototipação
É uma versão do sistema (ou de parte dele) desenvolvida rapidamente para verificar as necessidades do cliente e a 
viabilidade de algumas decisões de projeto. Esse processo previne mudanças, já que permite aos usuários/clientes 
experimentarem o sistema antes da entrega e, então, refinarem seus requisitos. Outra vantagem é que quando 
os requisitosestão obscuros, esse paradigma da prototipação auxilia os desenvolvedores a compreenderem 
melhor o que será ou está sendo construído. Consequentemente, as mudanças de requisitos a serem feitas após 
a entrega do software serão bem reduzidas.
Usuario
Nota
EVOLUCIONÁRIO MANDA VERSÕES EX WINDOWS
24
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
Figura 7 – Paradigma da prototipação
Construção
de um
protótipo
Modelagem
Projeto rápido
Comunicação
Emprega
Entrega e 
Realimentação
Projeto 
rápido
Fonte: PRESSMAN; MAXIM, 2016.
A figura 7 apresenta o paradigma da prototipação, que é composto por cinco fases.
• A comunicação é a fase em que o modelo se inicia. Nesta fase, ocorre uma reunião com os envolvidos 
no projeto para definir os objetivos gerais do software, identificar quais requisitos já são conhecidos e 
esquematizar quais áreas necessitam de uma definição de maiores detalhes.
• Na fase projeto rápido, é feito um projeto rápido que consiste em uma representação daqueles 
aspectos do software que serão visíveis aos usuários finais, por exemplo, o layout da interface com o 
usuário ou a forma como serão exibidas as informações/dados na tela. Tratará de um protótipo estático 
– sem navegação.
• As fases modelagem projeto rápido e construção de um protótipo se sobrepõem, pois referem-se à 
modelagem e construção de um protótipo dinâmico, ou seja, navegável. 
• A fase emprego, entrega e realimentação utiliza o protótipo dinâmico para fornecer um feedback dos 
usuários/clientes e, assim, aprimorar os requisitos. Esse protótipo também é utilizado para compreender 
melhor as necessidades que devem ser atendidas. Em suma, o protótipo atua como um mecanismo para 
identificar os requisitos do software.
Tanto clientes como desenvolvedores aprovam o modelo de prototipação, pois os clientes podem ter uma ideia 
de como ficará o produto final. No entanto, podem ocorrer problemas, como o cliente enxergar o protótipo 
como uma versão operacional do sistema e desejar a entrega rápida. O desenvolvedor frequentemente faz a 
implementação rápida para atender à vontade do cliente, porém terá como consequência a qualidade do software 
afetada.
Mas ainda que possam ocorrer problemas, a prototipação é um modelo de processo eficiente. No entanto, será 
preciso definir as regras desse modelo de processo logo no início do projeto e deixar o cliente ciente de que o 
protótipo será construído apenas para servir como um mecanismo de coleta e definição dos requisitos do sistema.
25
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
Modelo espiral
Foi proposto por Barry Boehm1 em 1988. O processo é representado por uma espiral, e não como uma sequência 
de atividades. Cada iteração na espiral representa uma fase do processo. Em cada iteração (ou ciclo), são 
reavaliados os riscos, por isso é dito que esse modelo é dirigido a riscos. Somente após a avaliação dos riscos, 
algum desenvolvimento é realizado. Em cada iteração, é ampliado o grau de definição e a implementação de 
um sistema.
A figura 8 ilustra as atividades do modelo espiral, em que cada iteração no espiral representa uma fase 
(comunicação, planejamento, modelagem, construção e emprego) do processo de software. 
Figura 8 – Modelo espiral típico
Fonte: PRESSMAN; MAXIM, 2016.
A primeira volta da espiral resulta no desenvolvimento de uma especificação de produto. Cada passagem pela 
região de planejamento resulta em ajustes no projeto do software. Custos e cronogramas podem ser reajustados 
conforme o feedback dos usuários/clientes após a entrega do produto. 
Esse modelo é bem diferente dos outros modelos de processos explicados anteriormente, que terminam somente 
quando o software é entregue. O modelo espiral é uma abordagem realista para o desenvolvimento de sistemas 
e de software de larga escala (PRESSMAN; MAXIM, 2016). Pelo fato de o software evoluir à medida que o processo 
avança, desenvolvedores e clientes reagem melhor aos riscos de cada iteração das atividades dos processos 
conforme avançam. Esse modelo utiliza a prototipação para a redução dos riscos em cada etapa. Os riscos são 
explicitamente avaliados e resolvidos ao longo do processo.
2.3 O processo unificado
Processo unificado é uma tentativa de aproveitar as melhores características dos modelos tradicionais. São os 
modelos de processos apresentados na Seção 2.2. O processo unificado destaca a importância da comunicação 
com o cliente e da utilização de diagramas de casos de uso para descrever a visão do cliente sobre um sistema. 
1 Para saber mais sobre Barry Boehm, acesse o site: . Acesso em 31 out 2018.
https://en.wikipedia.org/wiki/Barry_Boehm
26
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
O processo unificado é um modelo iterativo constituído de fases. Pressman e Maxim (2016) identificam cinco 
fases distintas no modelo do processo de software. A figura 9 descreve as cinco fases do processo unificado 
(concepção, elaboração, construção, transição e produção) e também as relaciona com as atividades genéricas 
(comunicação, planejamento, modelagem, construção e emprego) (vide Seção 2). 
Figura 9 – O processo unificado
Fonte: PRESSMAN; MAXIM, 2016.
A fase de concepção envolve as atividades de comunicação e as de planejamento. Nessa fase, em conjunto 
com os interessados (clientes), são identificados os requisitos fundamentais do negócio de forma preliminar. É 
também modelada uma arquitetura de alto nível que será expandida e refinada em fases posteriores. Com base 
nessas informações, são identificados os recursos, os principais riscos e é definido um cronograma, que será a 
base para as fases posteriores.
A fase de elaboração envolve as atividades de comunicação e modelagem. Nela, ocorre o detalhamento 
dos requisitos de software e o desenvolvimento de uma arquitetura executável (arquitetura implementável). A 
arquitetura inclui cinco visões: (i) modelo de caso prático; (ii) modelo de requisitos; (iii) modelo de projeto; (iv) 
modelo de implementação; (v) modelo de emprego. Na fase de elaboração, o planejamento é revisado para 
garantir que o escopo, os riscos e o prazo de entrega sejam alcançáveis. A arquitetura ainda não oferece todas 
as funções e recursos do sistema, mas o suficiente para demonstrar a sua viabilidade. Essa arquitetura não é um 
protótipo, uma vez que não será descartada, e sim será a base para as fases seguintes. 
A fase de construção refere-se à atividade de construção definida para o processo de software tradicional. 
A arquitetura é completada, então é realizada a implementação do código-fonte. São realizados os testes 
unitários e as atividades de integração dos componentes, bem como os testes de integração. Antes da realização 
da fase de transição, o software é confrontado contra os testes de aceitação. 
A fase de transição é o último estágio da iteração. Nela, são produzidos a documentação e os materiais de apoio 
(instalação, configuração, ajuda do software). O software é entregue aos usuários finais para o teste beta. 
27
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
A fase de produção condiz com a atividade de emprego do processo tradicional. Nessa fase, ocorre o 
monitoramento do uso contínuo do software, disponibilização de suporte para o software, realização e avaliação 
de relatórios de defeitos e também a solicitação de mudanças. Em suma, nessa fase é esperado que se tenha o 
software documentado e funcionando corretamente em seu ambiente operacional. 
O processo unificado não é um processo adequado para todos os tipos de software, como os softwares embutidos. 
Entretanto, ele representa uma abordagem que combina três modelos de processos: modelo cascata, modelo de 
processo incremental e engenharia de software orientada a reuso (SOMMERVILLE, 2011).
Para saber mais sobre teste beta, leia o artigo disponível em: .Acesso em: 30 jun. 2018.
Para saber mais sobre processo unificado, leia o artigo disponível em: . Acesso em: 30 jun. 2018.
Para saber mais sobre engenharia de software orientada a reuso, leia o artigo disponível em: 
. Acesso em: 30 jun. 2018.
Saiba mais
2.4 Modelo de processo pessoal (PSP)
O modelo de processo pessoal (PSP) foi criado em 1997 por Watts Humphery 2. É um processo de software projetado 
para a medição pessoal do desenvolvedor. Ele também responsabiliza o desenvolvedor pelo planejamento de 
projetos e dá a capacidade de controlar a qualidade de todos os artefatos de softwares desenvolvidos. Esse modelo 
define cinco atividades estruturais. 
• Planejamento: essa atividade faz o planejamento do software, que inclui as estimativas de defeitos, 
identificação de tarefas de desenvolvimento e elaboração de um cronograma de projeto. Registram-se 
todas as métricas em formulários ou planilhas.
• Projeto de alto nível: refere-se ao desenvolvimento de especificações externas para cada componente 
que será construído e também a elaboração de um projeto de componentes. Se for necessário, pode-se 
construir protótipos para melhor compreender o software. Todos os problemas são registrados.
• Revisão de projeto de alto nível: nessa atividade, são aplicados métodos de verificação formais para 
revelar erros no projeto. As medições são mantidas para todos os resultados de trabalho e tarefas 
importantes.
2 Para saber mais sobre Watts Humphery, acesse o site: . Acesso 
em: 31 out. 2018.
https://www.tecmundo.com.br/macos/1698-o-que-sao-versoes-alfa-beta-rc-e-final-.htm
https://www.tecmundo.com.br/macos/1698-o-que-sao-versoes-alfa-beta-rc-e-final-.htm
https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
https://medium.com/omarelgabrys-blog/software-engineering-software-process-and-software-process-models-part-2-4a9d06213fdc
https://medium.com/omarelgabrys-blog/software-engineering-software-process-and-software-process-models-part-2-4a9d06213fdc
https://en.wikipedia.org/wiki/Watts_Humphrey
28
Engenharia de Software | Unidade 2 - Modelos do Ciclo de Vida do Software
• Desenvolvimento: é nessa atividade que o código é gerado, revisado, compilado e testado. As medições 
são mantidas para todos os resultados de trabalho e tarefas importantes. 
• Autópsia: por meio de medidas e métricas coletadas, é determinada a eficácia do processo. As mudanças 
no processo serão realizadas conforme o resultado das medições e das métricas.
O PSP reforça a necessidade de identificar erros precocemente e também a importância de compreender os tipos 
de erros que provavelmente ocorrerão.
Para saber mais sobre Processo Pessoal (PSP), leia o artigo disponível em: . Acesso em: 30 jun. 2018.
Saiba mais
Síntese da unidade
Nesta unidade, você aprendeu os principais modelos de processos de software, além de:
• Diferenciar qual modelo de processo de software utilizar, dependendo do tipo e tamanho do software que 
será desenvolvido.
• Identificar quais são as principais características de cada modelo de processo de software.
• Descrever o que é processo unificado e processo pessoal (PSP).
29
Considerações finais
Esperamos que você tenha conseguido assimilar da melhor forma possível 
o conteúdo aqui apresentado. Para ampliar o seu conhecimento, consulte 
o aprofundamento de conteúdo e assista à videoaula da unidade, pois 
contêm informações relevantes para seu aprendizado. 
30
 3Unidade 3
3. Engenharia de Requisitos e 
Modelagem de Software 
Para iniciar seus estudos
Nesta unidade, você verá os conceitos de requisitos de software e os 
processos envolvidos na descoberta e documentação de requisitos. 
A compreensão dos requisitos de software está entre as tarefas mais 
difíceis da engenharia de software. Vamos lá?
Objetivos de Aprendizagem
• Definir requisitos de software.
• Definir os requisitos de usuário e de sistemas.
• Identificar e explicar as diferenças entre os requisitos de software 
funcionais e não funcionais.
• Identificar a importância do levantamento dos requisitos para 
projetos de software.
• Identificar as técnicas ideais para descobrir (levantar) os requisitos 
do software a ser desenvolvido.
31
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Introdução da unidade
Nesta unidade, iniciaremos os estudos sobre conceitos que lhe permitirão entender a importância dos requisitos 
de software e também realizar a descoberta e a validação destes. Apresentaremos algumas técnicas utilizadas 
para a elicitação (ou levantamento) dos requisitos de software. Para isso, trabalharemos com base nos seguintes 
questionamentos:
• O que são requisitos de software?
• Quais são os tipos de requisitos de software e como diferenciar requisitos funcionais dos requisitos não 
funcionais?
• Quais são as técnicas utilizadas para levantamento dos requisitos de software? 
• É possível combinar uma ou mais técnicas no momento do levantamento de requisitos?
3.1 Engenharia de requisitos
Segundo Sommerville (2011), os requisitos de software consistem em detalhar o que o sistema deve fazer, quais 
serviços deve oferecer e quais as limitações em relação ao seu funcionamento. A compreensão de requisitos 
de software está entre as tarefas mais difíceis enfrentadas pelos engenheiros de software. Isso ocorre porque o 
cliente muitas vezes não sabe verbalizar suas necessidades ou não sabe o que é realmente necessário que o seu 
software faça. Outro problema é a alteração de requisitos ao longo do processo do software, pois, à medida que o 
desenvolvimento avança, o cliente pode sentir a necessidade de alguma funcionalidade ou mesmo considerar 
outra como desnecessária. 
Diante dessas dificuldades, surgiu a necessidade da criação de uma técnica – a engenharia de requisitos – para 
facilitar o entendimento das necessidades dos clientes antes de se projetar o software. A engenharia de requisitos 
fornece um mecanismo para entender aquilo que o cliente deseja por meio da análise de suas necessidades, 
avaliação da viabilidade, negociação de uma solução razoável, especificação da solução sem ambiguidades, 
validação da especificação e gerenciamento das necessidades à medida que são transformadas em um sistema 
operacional (PRESSMAN, 2016). 
A engenharia de requisitos abrange sete tarefas distintas; algumas delas ocorrem em paralelo, e todas são 
adaptadas às necessidades do projeto. De acordo com Pressman (2016), as sete tarefas são:
1. Concepção – consiste em compreender o problema, propor uma solução para resolvê-lo e entender 
o que o cliente deseja. A eficácia da comunicação e colaboração iniciais entre o cliente e a equipe de 
software também é essencial. 
2. Levantamento – esta tarefa transparece ser a mais simples; no entanto, é um equívoco. Inicialmente, 
parece que basta perguntar ao cliente o que ele deseja que o seu software tenha e faça, qual será a 
sua utilização, quantos usuários finais o sistema terá, entre outras informações. Porém, existem alguns 
problemas como: (i) problemas de escopo (os clientes/usuários especificam de forma precária ou com 
detalhes desnecessários as necessidades do sistema, o que pode levar à confusão dos objetivos globais 
do softwareque será desenvolvido); (ii) problemas de entendimento (os clientes/usuários têm dificuldade 
em transmitir suas necessidades, omitem informações que, para eles, parecem ser desnecessárias 
ou então especificam requisitos ambíguos; tal fato ocorre porque os clientes/usuários não estão 
32
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
completamente certos do que será preciso no software que desejam); (iii) problemas de volatilidade (os 
requisitos mudam à medida que o projeto do software avança; para amenizar esse problema, devemos 
realizar o levantamento de requisitos de forma organizada). 
3. Elaboração – consiste em descrever o problema com base nas informações obtidas nas duas tarefas 
anteriores; dessa forma, será estabelecida uma base concreta para o projeto. A elaboração é orientada 
pela criação e refinamento de cenários de usuários que descrevem como o usuário final interagirá 
com o sistema. Após a análise desses cenários, será possível extrair classes, seus atributos e métodos. 
As relações e a colaboração entre as classes serão identificadas; além disso, outros diagramas da UML 
(unified modeling language) poderão ser produzidos.
4. Negociação – esta tarefa é a responsável por mediar possíveis conflitos. Por exemplo, clientes e 
usuários podem solicitar mais recursos do que o permitido – considerando a limitação dos recursos de 
negócio – ou, então, clientes e usuários podem propor necessidades conflitantes, argumentando que 
sua necessidade é mais importante do que a do outro. Por exemplo, clientes e usuários podem solicitar 
mais recursos do que é possível atingir devido à limitação dos recursos de negócio ou, então, propor 
necessidades conflitantes, argumentando que sua necessidade é maior do que a do outro. Todos esses 
conflitos devem ser conciliados por meio da negociação. Para que a negociação aconteça, é solicitado 
aos clientes e usuários que decidam qual será a prioridade dos requisitos a serem implementados. Após a 
reunião dos clientes e usuários, alguns requisitos podem ser eliminados, combinados ou modificados, de 
forma que todos os envolvidos no projeto fiquem satisfeitos.
5. Especificação – esta tarefa pode ser um documento por escrito, um conjunto de modelos gráficos, 
um modelo matemático formal, um conjunto de cenários (diagramas) de casos de uso, um protótipo 
ou qualquer combinação dos fatores anteriores. Para sistemas pequenos, bastam diagramas de casos 
de uso; no entanto, para sistemas grandes, se faz necessário um documento por escrito, que contenha 
descrições claras para o cliente e modelos gráficos. O importante é que a especificação seja clara e 
relate a necessidade que o cliente solicitou nas tarefas anteriores. A Figura 1 ilustra o sumário (títulos e 
subtítulos esperados) de um pequeno modelo de especificação de requisitos de software. Trata-se de um 
documento com uma descrição mais detalhada de todas as características do software que se pretende 
desenvolver. A especificação de requisitos deve ser feita antes do início do projeto do software. 
Quadro 1 – Modelo de especificação de requisitos de software
Sumário
Histórico de Revisão
1. Introdução
1.1. Propósito
1.2. Convenções do documento
1.3. Público-alvo e sugestão de leitura
1.4. Escopo do projeto
1.5. Referências
33
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
2. Descrição geral
2.1. Perspectiva do produto
2.2. Características do produto
2.3. Classes de usuários e características
2.4. Ambiente operacional
2.5. Restrições de projeto e implementação
2.6. Documentação para usuários
2.7. Hipóteses e dependências
3. Características do sistema
3.1. Características do sistema 1
3.2. Características do sistema 2
3.3. Características do sistema n
4. Requisitos de interfaces externas
4.1. Interfaces do usuário
4.2. Interfaces de hardware
4.3. Interfaces de software
4.4. Interfaces de comunicação
5. Outros requisitos não funcionais
5.1. Necessidades de desempenho
5.2. Necessidades de proteção
5.3. Necessidades de segurança
5.4. Atributos de qualidade de software
6. Outros requisitos
Apêndice A: Glossário
Apêndice B: Modelos de análise
Apêndice C: Lista de problemas
Fonte: Adaptado de PRESSMAN; MAXIM, 2016.
34
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
6. Validação – é nesta tarefa que se avalia a qualidade dos artefatos (documentos, diagrama UML). Essa 
avaliação é feita através da verificação da especificação de requisitos; assim, é possível garantir que 
todos os requisitos tenham sido declarados sem ambiguidade, sem inconsistências, sem omissões e 
sem erros. A tarefa de validação também permite verificar se os artefatos seguem o padrão estabelecido 
para o processo e projeto do software. A principal forma de validação é por meio da revisão técnica, cuja 
equipe responsável é formada, geralmente, pelos desenvolvedores, clientes e usuários. Essa equipe tem 
a tarefa de examinar a especificação de requisitos procurando por erros no conteúdo do documento, por 
informações faltantes, inconsistências de requisitos, requisitos heterogêneos ou mesmo requisitos falsos. 
7. Gestão de requisitos – a gestão de requisitos é relevante, pois a necessidade de alterações nos requisitos 
de software persiste ao longo da vida de um sistema. Essa tarefa consiste em um conjunto de atividades 
para ajudar a equipe da revisão técnica a reconhecer, inspecionar e conduzir as alterações que decorrem 
enquanto o projeto continua. 
3.2 Requisitos de software
Requisitos de software consistem no detalhamento dos serviços e restrições do software que será desenvolvido. 
Todos os requisitos que os clientes/usuários desejam e/ou precisam devem ser reproduzidos em um documento 
denominado documento de especificação do sistema. 
O processo – que envolve as tarefas de levantamento (descobrir), análise, documentação e verificação de 
requisitos – é denominado engenharia de requisitos, conforme explicado na seção anterior.
A tarefa de levantamento de requisitos pode produzir diferentes níveis de descrição do sistema. Essas descrições 
podem se aproximar mais dos usuários ou dos desenvolvedores. Sommerville (2011) apresenta dois níveis de 
abstração: 
• Requisitos de usuário – são utilizados para expressar os requisitos abstratos de alto nível. Referem-se às 
declarações de quais serviços o sistema fornecerá a seus usuários e as restrições com as quais este deve 
operar. Utiliza-se de uma linguagem natural com diagramas.
• Requisitos de sistema – são utilizados para expressar a descrição detalhada do que o sistema deve 
fazer. Referem-se às descrições mais detalhadas das funções, dos serviços e restrições operacionais 
do sistema de software. O documento de requisitos do sistema deve definir exatamente o que deverá 
ser implementado. Pode ser parte do contrato entre o comprador do sistema e os desenvolvedores do 
software.
O Quadro 2 apresenta a distinção entre os requisitos de usuários e de sistemas. Apresenta também como um 
requisito de usuário pode ser expandido em vários requisitos de sistemas. Para ilustrar esses tipos de requisito, 
utilizaremos um exemplo de um sistema de vendas.
Quadro 2 – Requisitos de usuário e de sistemas
Definição de Requisitos de Usuários
1- O sistema deve gerar relatórios mensais que mostrem a quantidade de produtos vendidos no mês 
vigente.
35
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Especificação de Requisitos de Sistemas
1.1- No último dia útil de cada mês deve ser gerado um resumo dos produtos mais vendidos.
1.2- O acesso aos relatórios deve ser restrito a usuários autorizados.
Fonte: Elaborado pela autora.
Os requisitos precisam ser escritos em termos de detalhamento de acordo com o tipo de leitores 
existentes. Os requisitos de usuários possuem os seguintes leitores: gerentes clientes, usuários 
finais do sistema, engenheiros clientes, engenheiros contratantese arquitetos de sistema. 
Esses leitores geralmente não se preocupam com a forma como o sistema será implementado. 
Já os leitores dos requisitos de sistemas são: usuários finais do sistema, engenheiros clientes, 
arquitetos de sistemas e desenvolvedores de software. Esses leitores precisam saber as 
informações com mais detalhes, pois eles estão envolvidos na implementação do sistema.
Fique atento!
Além dos tipos de requisitos (de usuário e de sistema), os requisitos de software são classificados como requisitos 
funcionais e requisitos não funcionais, conforme veremos na seção abaixo.
3.3 Requisitos funcionais
Os requisitos funcionais descrevem o que um sistema deve fazer e como deve se comportar em determinadas 
situações, ou seja, capturam as funcionalidades sob o ponto de vista do cliente. No entanto, os requisitos funcionais 
dependem do tipo de software que será desenvolvido, de quem são seus possíveis usuários e da metodologia 
de escrita dos requisitos adotada pela empresa. Por exemplo, em um sistema de comércio eletrônico alguns 
requisitos funcionais seriam: (i) permitir a consulta de produtos por preço; (ii) permitir a consulta dos produtos por 
nome; (iii) permitir a consulta dos produtos mais vendidos; (iv) permitir pagamento online via cartão de crédito ou 
boleto bancário; e (v) cadastramento de clientes. 
A imprecisão na especificação dos requisitos causa muitos problemas na engenharia de software. Por isso, a 
especificação dos requisitos funcionais de um sistema deve ser completa (todos os serviços requeridos pelo 
usuário devem ser definidos) e consistente (os requisitos não devem ter definições contraditórias).
36
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
3.4 Requisitos não funcionais
Os requisitos não funcionais referem-se às restrições a serviços ou funções oferecidos pelo sistema, ou seja, 
trata-se dos requisitos que não estão diretamente relacionados com os serviços oferecidos pelo sistema a seus 
usuários. Em um sistema de comércio eletrônico, por exemplo, normalmente os clientes não têm paciência para 
aguardar o carregamento de uma página demorada e desistem da compra. Assim, esse tipo de sistema deverá 
ter como requisito não funcional o carregamento rápido de páginas, com o limite de tempo de, no máximo, 2 
segundos, por exemplo.
Ao desenvolver um novo software, os desenvolvedores e engenheiros de software indicam um conjunto de 
requisitos não funcionais que o software deverá possuir, como:
• Confiabilidade – refere-se à capacidade do software de preservar o seu nível de desempenho quando 
usado em condições predeterminadas. Exemplo: o software deve evitar falhas resultantes de defeitos. 
• Desempenho – refere-se ao tempo de execução e aos recursos disponíveis no computador. Exemplo: o 
sistema não deve consumir muitos recursos (como memória) do computador, nem demorar muito para 
executar os processos.
• Segurança – refere-se à capacidade do software de proteger informações e dados de forma que usuários 
não autorizados não tenham acesso, nem mesmo para leitura. Exemplo: o sistema deve garantir a 
segurança dos dados por meio do uso de senhas criptografadas.
Os requisitos não funcionais surgiram da necessidade dos usuários e também das restrições de orçamento, das 
políticas das organizações, das necessidades de interoperabilidade com outros sistemas de software ou hardware 
e de fatores externos, como regulamentos de segurança ou leis sobre privacidade. A Figura 10 apresenta a 
classificação dos requisitos não funcionais, que estão divididos em: 
• Requisitos de produto – são utilizados para especificar ou restringir o comportamento do software, 
como, por exemplo, os requisitos de confiabilidade que estabelecem a taxa aceitável de falhas. 
• Requisitos organizacionais – são os requisitos gerais de sistemas derivados a partir da política interna da 
empresa do cliente e do desenvolvedor. Exemplo: os requisitos operacionais que definem como o sistema 
será usado. 
• Requisitos externos – abrangem todos os requisitos que derivam de fatores externos ao sistema e seu 
processo de desenvolvimento, como, por exemplo, os requisitos legais que devem ser seguidos para 
garantir que o sistema opere dentro da lei.
37
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Figura 10 – Tipos de requisitos não funcionais
Requisitos não
funcionais
Requisitos do
produto
Requisitos de
eficiência
Requisitos de
facilidade de uso
Requisitos de
desempenho
Requisitos de
espaço
Requisitos de
privacidade
Requisitos de
segurança
Requisitos de
entrega
Requisitos de
implementação
Requisitos de
padrões
Requisitos legais
Requisitos de
confiabilidade
Requisitos de
portabilidade
Requisitos de
interoperabilidade
Requisitos éticos
Requisitos 
organizacionais
Requisitos 
externos
Fonte: SOMMERVILLE, 2011.
3.5 Levantamento de requisitos
O levantamento de requisitos, também conhecido como elicitação de requisitos, é uma atividade que combina 
elementos de resolução de problemas, elaboração, negociação e especificação de requisitos. Nesta atividade, 
os engenheiros de software trabalham com clientes e usuários finais do software que será produzido para obter 
informações sobre os serviços que o sistema deve oferecer, o contexto da aplicação, o desempenho do sistema, 
as restrições de hardware, entre outros. 
A Figura 11 apresenta um modelo do processo de levantamento de requisitos. É importante ressaltar que cada 
empresa deve ter sua própria versão, pois essa atividade sofre influência de fatores locais, como conhecimento 
dos usuários finais, do tipo e tamanho do sistema a ser produzido, da política interna da empresa, entre outros.
38
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Figura 11 – Processo de levantamento e análise de requisitos
1. Descoberta
de requisitos
2. Classificação e
organização de
requisitos
3. Priorização e
negociação de
requisitos
4. Especificação
de requisitos
Fonte: SOMMERVILLE, 2011.
As atividades do processo de levantamento e análise de requisitos são:
1. Descoberta de requisitos – nesta atividade, ocorre um diálogo com os clientes e usuários finais a fim de 
se descobrir os requisitos do software a ser desenvolvido. 
2. Classificação e organização de requisitos – após a realização da atividade de descoberta dos requisitos, 
são feitas a classificação e a organização destes. Assim, os requisitos comuns são agrupados no mesmo 
grupo, e os requisitos redundantes são descartados. Essa atividade permite a eliminação de requisitos 
desnecessários e garante que todos os requisitos comuns tenham sido agrupados corretamente para 
facilitar a criação das funcionalidades do software.
3. Priorização e negociação de requisitos – essa atividade está relacionada à priorização, ou seja, dentre 
os requisitos listados pelos clientes e usuários finais, quais deverão ser desenvolvidos primeiro. Para 
decidir a priorização dos requisitos é realizada uma reunião entre os clientes e usuários finais para que 
eles decidam qual a prioridade ou qual a precedência das funcionalidades na hora da implementação do 
software.
4. Especificação de requisitos – consiste em escrever os requisitos de usuários e de sistema em documento 
de requisitos. Documentos formais podem ser produzidos conforme modelo apresentado anteriormente. 
No estágio inicial, uma versão do documento de requisitos com seções faltantes e requisitos incompletos 
pode ser produzida. Uma alternativa a esse modelo fechado é documentar em cartões os requisitos, pois 
é mais fácil para os clientes e usuários finais se organizarem e modificarem os requisitos.
39
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
O processo de elicitar e compreender requisitos é árduo, pois frequentemente os clientes e usuários finais 
(também chamados de partes interessadas) possuem opiniões distintas sobre a importânciae prioridade dos 
requisitos, e geralmente as opiniões são conflitantes. Diante desse problema, a engenharia de software propôs as 
seguintes técnicas de elicitação de requisitos: 
• Descoberta de requisitos sob ponto de vista.
• Entrevistas.
• Casos de uso.
• Etnografia.
Assista ao vídeo para 
saber sobre os requisitos de software.
Saiba mais
3.6 Descoberta de requisitos sob ponto de vista
A descoberta de requisitos consiste no processo de reunir informações como documentação, clientes e usuários 
finais, e especificações similares sobre o sistema a ser produzido. Dessas informações serão separados os 
requisitos de usuários e de sistemas. 
As partes interessadas de um software variam muito, seja pelo tamanho da empresa, quantidade de usuários 
(partes interessadas), tipos de sistemas que interagem ou simplesmente pelo tamanho do sistema a ser 
desenvolvido. Durante o processo de levantamento de requisitos, todas essas fontes de requisitos devem 
ser consideradas. Porém, como existem muitas fontes, consequentemente têm-se muitos pontos de vistas 
distintos sobre o mesmo problema. Em suma, pessoas distintas “enxergam” o mesmo requisito sob um ponto 
de vista diferente umas das outras, mas, apesar de os requisitos serem expressados de formas distintas, não são 
completamente independentes; basta os engenheiros de software realizarem uma “filtragem” dos requisitos 
duplicados e inconsistentes.
Portanto, a técnica de descoberta de requisitos sob pontos de vistas é utilizada para estruturar a elicitação e a 
documentação dos requisitos do software. A Figura 12 apresenta os requisitos sob o ponto de vista de um titular 
e de um não titular de uma conta em alguma agência bancária.
http://www.no-ads-youtube.com/video/b-son-treinamentos/o-que-levantamento-de-requisitos-t-picos-de-engenharia-de-software?v=VcOeM2AD8Yk
http://www.no-ads-youtube.com/video/b-son-treinamentos/o-que-levantamento-de-requisitos-t-picos-de-engenharia-de-software?v=VcOeM2AD8Yk
40
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
Figura 12 – Exemplo de descoberta de requisitos sob pontos de vista
Titular da conta
 Lista de Serviços
Sacar dinheiro
Depositar dinheiro
Consultar saldo
Solicitar extratos
Transferir dinheiro
Não Titular da conta
 Lista de Serviços
Depositar dinheiro
Fonte: Elaborada pela autora.
3.7 Entrevistas
Outra técnica para descobrir os requisitos de software são entrevistas formais ou informais. As entrevistas podem 
ser de dois tipos: 
• Entrevistas fechadas – consistem nas partes interessadas responderem a um questionário com 
perguntas predefinidas.
• Entrevistas abertas – não têm um conjunto de perguntas predefinidas. A equipe dos engenheiros de 
software se adapta para explorar o conhecimento das partes interessadas. Assim, desenvolve uma melhor 
compreensão das necessidades desses usuários/clientes.
A técnica de entrevista é considerada uma boa forma de compreensão dos requisitos de modo global, mas não 
para os requisitos do domínio da aplicação, pois o conhecimento desse tipo de requisito é tão familiar às partes 
interessadas que elas têm dificuldades em expô-los ou simplesmente não mencionam por não julgar necessário 
aos engenheiros de software.
A técnica de entrevistas pode não capturar informações essenciais do sistema, não devendo 
ser utilizada sozinha, mas, sim, em conjunto com outras técnicas de elicitação de requisitos. 
Fique atento!
Assista ao vídeo Gerenciamento de Requisitos sem Mistério, no YouTube, para saber sobre 
como gerenciar os requisitos de software e saber mais sobre as técnicas de levantar requisitos.
Saiba mais
41
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
3.8 Casos de uso
Os diagramas de casos de uso também são uma técnica de elicitação de requisitos. Sua forma simples permite 
ilustrar às partes interessadas a interação com o sistema por meio de atores (usuário que interagirá com 
determinada tela do sistema) e casos de uso (telas dos sistemas).
A Figura 13 representa um conjunto de casos de usos de todas as possíveis interações que o usuário final terá de 
acordo com os requisitos descobertos. Os atores (o bonequinho palito) representam todas as possíveis interações 
que os usuários finais ou outros sistemas terão com o software a ser desenvolvido. Já as linhas representam a 
ligação dos atores com os seus respectivos casos de uso.
Figura 13 – Exemplo de um caso de uso para parte do sistema de uma biblioteca
Atendente
Emprestar 
Livro
Devolver 
Livro
Incluir Livro
Comprar Livro
Bibliotecária
Fonte: Elaborada pela autora.
Casos de uso são considerados boas técnicas para descobertas de requisitos por mostrar a interação das partes 
interessadas (usuários, por exemplo) com o sistema. No entanto, devido ao fato de o foco do diagrama de caso de 
uso estar nas interações com o sistema (ou seja, com quais funcionalidades os usuários interagirão), o diagrama 
caso de uso não é eficaz para descobrir:
42
Engenharia de Software | Unidade 3 - Engenharia de Requisitos e Modelagem de Software 
• As restrições do sistema, que se referem às limitações internas ou externas ao projeto do software. 
Por exemplo, toda a equipe do projeto deverá ser contratada via CLT; portanto, não poderá haver contrato 
terceirizado.
• Os requisitos de negócio ou regras de negócio, que se referem às políticas de negócio, ou seja, 
declarações em relação à forma da empresa realizar as suas atividades. As regras de negócio servem para 
atender os objetivos do negócio (em relação ao sistema) e do cliente e, também, para cumprir às leis/
regras do negócio. Por exemplo: o professor somente poderá lecionar disciplinas relacionadas à sua linha 
de pesquisa do mestrado ou, então, o cliente do Banco do Brasil só poderá realizar um saque na sua conta 
de apenas mil reais por dia. 
• Os requisitos não funcionais (já explicados e exemplificados anteriormente).
Conforme apresentado, o diagrama de caso de uso tem algumas limitações que impedem a captura de todos 
os tipos de requisitos do projeto do sistema. Devido a esse fato, o diagrama de caso de uso deve ser utilizado 
em conjunto com outros diagramas; por exemplo, o diagrama de atividades e os diagramas de sequência e de 
colaboração. O diagrama de atividades descreve o fluxo de atividades de um caso de uso. Já os diagramas de 
sequência e de colaboração descrevem as interações entre o ator e o comportamento dos objetos de um caso 
de uso do sistema.
Visite o site da OMG (Object Management Group) para saber mais informações sobre os diagramas de casos de uso 
pertencentes à modelagem UML (unified modeling language).
Para saber mais sobre os diagramas de atividades, sequência e de colaboração, acesse o site: 
.
Saiba mais
3.9 Etnografia
A etnografia consiste em uma técnica de observação utilizada para descobrir os requisitos sociais e organizacionais. 
Para tal, o engenheiro de software (ou analista) se insere no ambiente de trabalho da empresa para qual será 
desenvolvido o software e observa o dia a dia de trabalho, ou seja, a rotina da empresa. São observadas e anotadas 
todas as tarefas realizadas pelas partes interessadas. 
A vantagem dessa técnica em relação às outras é que ela ajuda na descoberta dos requisitos implícitos, pois, com 
ela, é possível capturar informações sobre situações reais em vez de processos formais definidos pela empresa.
A desvantagem da etnografia é que o seu foco está voltado para o usuário final, o que muitas vezes não permite 
a descoberta dos requisitos organizacionais ou de domínio. Consequentemente, esses usuários não sabem 
identificar e informar novos recursos que devam ser adicionados ao sistema.
43
Engenharia