Ebook Engenharia de Software

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE 
 
 
 
APRESENTAÇÃO
Seja bem-vindo(a) à disciplina de Engenharia de Software. 
O desenvolvimento de software é desafiador e exige conhecimento especializado. 
O resultado desse processo são produtos que ajudam as pessoas em suas atividades. O 
editor de texto, a planilha eletrônica, o slide de apresentação, os aplicativos em nosso 
celular, os sistemas utilizados pelas empresas para apoio em suas atividades, entre outros, 
são produtos de software. Ao tratarmos de Engenharia de Software, devemos considerar 
os bastidores dessa área, pois o processo de construção de um produto de software 
é complexo, mas muito bem estruturado e organizado. Estamos falando um processo 
devidamente definido, com papéis e responsabilidades, ferramentas de apoio, modelos, 
frameworks, padrões e boas práticas para apoiarem na realização das atividades de 
trabalho.
INTRODUÇÃO
Olá, aluno(a)! Neste conteúdo, aprofundaremos nossos conhecimentos sobre a 
engenharia de software.
De acordo com Sommerville (2011), o nome “engenharia de software” foi proposto 
em 1969, em uma conferência da OTAN (Organização do Tratado do Atlântico Norte), 
para a discussão de problemas relacionados com desenvolvimento de software.
Não há dúvida de que o software facilita a nossa vida, pois ele está presente nos 
mais diversos momentos. Seja no aplicativo de celular, no site da internet, no controle 
que precisamos realizar, no texto ou na apresentação que necessitamos desenvolver, o 
software está facilitando consideravelmente a execução das nossas atividades. 
Existem diversos aplicativos de software, como planilhas eletrônicas, editores 
de texto, aplicativos de mensagens e redes sociais, que são aplicações resultantes do 
desenvolvimento de software. O software ajuda na organização da nossa rotina de 
trabalho, um exemplo disso é a organização de sinais dos semáforos nas ruas e avenidas 
em que passamos, pois existem aplicações de software fazendo o seu controle. O software 
está em aplicações dos mais variados níveis de criticidade, que vão desde o registro do 
controle de ponto do trabalhador até aplicações do mais alto grau de criticidade, como o 
controle de tráfego aéreo, de represas hidroelétricas e de usinas nucleares. 
Se o software pode estar presente nos mais variados níveis de aplicações – das 
simples até as mais críticas – torna-se necessário um processo minucioso para o seu 
desenvolvimento. Esse é o ponto principal, sobre o qual trataremos, incluindo diversas 
ferramentas, modelos e processos que podem ser aplicados para que possamos produzir 
software de altíssima qualidade, livre de erros e executando o que ele se propõe a fazer.
ENGENHARIA DE SOFTWARE
Na década de 60, as entregas dos softwares atrasavam, não entregavam as 
funcionalidades que os usuários necessitavam, custavam mais que o esperado e não 
eram confiáveis. Emergindo ao final da década de 60 e ganhando força no início da 
década de 70, surge a chamada crise do software. Começava a existir uma alta demanda 
no desenvolvimento de sistemas, os profissionais de tecnologia se deparavam com a 
complexidade dos problemas a serem resolvidos e, além de tudo isso, não havia técnicas 
definidas para o desenvolvimento que garantissem o funcionamento adequado das 
soluções.
Projetos com prazo e orçamento comprometidos, produto com baixa qualidade, 
sistema gerando insatisfação aos usuários, alta dificuldade no gerenciamento das 
atividades, escassez de pessoas preparadas para a função (programadores e analistas de 
requisitos e sistemas) e códigos de difícil manutenção eram alguns dos sintomas gerados 
por essa crise.
O processo de criação de software era complexo e, agregado a isso, existia a 
imaturidade da engenharia de software como profissão, pois ainda começava a dar 
os primeiros passos. Dessa forma, surgia a necessidade da definição de um processo 
organizado que possibilitasse o desenvolvimento de produtos de software confiáveis, ou 
seja, a Engenharia de Software propriamente dita!
No contexto atual, o mundo não consegue mais evoluir sem um aplicativo de 
software. Produtos elétricos e eletrônicos, veículos, sistemas de controle de aeronaves, 
programas de celular, tablets e computadores são exemplos que utilizam aplicativos de 
software para o seu funcionamento. 
A produção das indústrias é altamente informatizada pelo controle de aplicações 
do sistema financeiro, da indústria da música, de jogos, do cinema e da televisão, que 
são segmentos com uso intensivo de software. Sendo assim, a engenharia de software 
é essencial para o funcionamento de aplicativos que suportam esses segmentos. Mesmo 
que você não concorde, o software está incorporado em praticamente todos os aspectos 
de nossas vidas.
Para Pressman (2016), software é o elemento-chave na evolução de produtos e 
sistemas com base em computador, além de ser uma das mais importantes tecnologias 
no cenário mundial. Pressman (2016) também complementa que o software consiste em:
1. instruções (programas de computador) que, quando executadas, fornecem 
características, funções e desempenho desejados; 
2. estruturas de dados que possibilitam aos programas manipular informações 
adequadamente; e 
3. informação descritiva, tanto na forma impressa quanto na virtual, 
descrevendo a operação e o uso dos programas.
Para Sommerville (2011), é uma disciplina de engenharia cujo foco está em todos 
os aspectos da produção de software, desde os estágios iniciais da especificação do 
sistema até a sua manutenção, quando o sistema já está sendo usado. Como disciplina, 
a Engenharia de Software apoia o processo de desenvolvimento, sugerindo técnicas para 
especificação, projeto e evolução de programas de desenvolvimento de software.
De acordo com o IEEE (Instituto de 
Engenheiros Eletricistas e Eletrônicos), o 
software está profundamente incorporado 
em praticamente todos os aspectos de 
nossas vidas e, consequentemente, o 
número de pessoas interessadas nos 
recursos e nas funções oferecidas por 
determinada aplicação tem crescido 
significativamente. Se considerarmos a 
grande demanda de produção de sistemas 
que atualmente temos – e as que estão 
por vir – a Engenharia de Software passa 
a ter uma importância crítica para o futuro 
da humanidade.
É importante destacar que o 
objetivo da Engenharia de Software é 
fornecer informações e técnicas para 
o desenvolvimento e a produção de 
soluções. São métodos que envolvem 
uma ampla variedade de atividades e 
tarefas que vão desde a comunicação 
até análise de requisitos, modelagem 
de projetos, construção de programas, 
testes, verificação, validação, entrega 
e suporte. A Engenharia de Software 
inclui ainda métodos que se baseiam em 
princípios para orientar o levantamento 
e a descoberta de informações, a 
modelagem e outras técnicas descritivas.
Já as ferramentas da Engenharia de Software – que são muitas – fornecem 
suporte para o processo de desenvolvimento. Nesse aspecto, existe uma integração das 
informações que vão desde o levantamento dos requisitos, a organização do projeto – 
pessoas, atividades, orçamento, cronograma de entregas – até o desenvolvimento do 
código propriamente dito. Isso possibilita a definição de um sistema para o suporte 
ao desenvolvimento de software, denominado engenharia de software com o auxílio do 
computador.
Existe uma confusão sobre o software ser apenas o programa que roda no computador, 
porém é muito mais que isso. Ao nos referenciarmos ao termo engenharia de software, 
não estamos nos limitando apenas ao programa de computador em si, pois significa algo 
muito mais amplo. A engenharia de software considera toda a documentação associada, 
as configurações necessárias para que o programa opere corretamente, o trabalho, o 
processo para o seu desenvolvimento, os testes e a qualidade do produto, constituindo 
algo muito mais amplo e complexo.
 Um sistema de softwareé, com frequência, mais do que um programa de computador. 
Ele pode incluir outros programas separados e arquivos de configuração que são usados 
para permitir que o sistema opere. Inclui documentação do sistema e do usuário, existe 
uma descrição da sua estrutura e uma documentação de como usar o sistema. Agregado a 
ele, existem sites para que os usuários baixem as informações e as atualizações referentes 
ao produto. Estamos falando de um sistema profissional projetado para pessoas, e não de 
uma aplicação criada por um amador, que desenvolve um programa para si mesmo, que 
ninguém mais usará e, somente ele, o criador, compreende a solução.
A engenharia de software é um processo organizado de trabalho, existem etapas no 
processo e papéis bem definidos, além de práticas e ferramentas de apoio que possibilitam 
as empresas a adquirirem maturidade e melhorarem seus processos de construção de 
sistemas. Ela se faz importante – e, por assim dizer, necessária – por dois motivos:
• Pessoas e sociedades estão cada vez mais dependentes das soluções de 
sistemas de software;
• Existem ganhos de longo prazo que são obtidos com o uso e a aplicação 
de métodos e técnicas da engenharia de software. Não estamos falando apenas 
do aspecto financeiro, mas da facilidade de manutenção, confiabilidade do 
produto e economia oriunda por não haver retrabalho.
A demanda de software vem aumentando cada vez mais, e com a tecnologia cada dia 
mais acessível às pessoas, existe uma demanda crescente por soluções dos mais variados 
tipos e segmentos. Resta o desafio e a consciência de produzir sistemas confiáveis de 
forma rápida e econômica. Para que isso seja alcançado, torna-se necessário um processo 
de apoio – a Engenharia de Software. 
Concluímos aqui o nosso aprendizado sobre os conceitos da disciplina de Engenharia 
de Software. Esse é um conteúdo fascinante relacionado à área de Tecnologia da 
Informação e Comunicação (TIC).
Para que o seu conhecimento seja melhor construído, continue com pesquisas e 
leituras complementares.
Referências da unidade:
PRESSMAN, R. S. Engenharia de software: Uma Abordagem Profissional. 8. ed. 
São Paulo: AMGH Editora Ltda, 2016.
Software Engineering Institute – SEI. “CMMI for Development, Version 1.3”, CMMI-
-DEV V1.3, CMU/SEI 2010-TR-033, Relatório Técnico. Carnegie Mellon University, 
2010.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
INTRODUÇÃO
Olá, aluno(a)! Está preparado para conhecer a história da evolução do software? 
Vamos lá!
O desenvolvimento de software é um dos segmentos da Tecnologia da Informação 
e Comunicação (TIC) que mais demanda profissionais. Por estar em ascensão, existem 
muitas oportunidades, tanto no Brasil, como em outros países.
O trabalho de desenvolvimento de aplicações de software no contexto atual pode 
ser realizado de forma estruturada e organizada. Existem muitas ferramentas, frameworks 
e boas práticas para apoiar as atividades relacionadas a esse segmento, mas nem sempre 
foi assim...
Nos primórdios dos computadores, não havia programas instalados, logo, não 
havia maneira para que os softwares fossem desenvolvidos. Por isso, no encontro de 
hoje, estudaremos a história da evolução do software, os principais fatos históricos e os 
acontecimentos que causaram o crescimento dessa área – a Engenharia de Software.
CONHECER A HISTÓRIA DA EVOLUÇÃO DO SOFTWARE
Historicamente, profissionais de TIC que atuam especificamente no desenvolvimento 
de sistemas sempre tiveram boas oportunidades profissionais. Nesse setor, de 
desenvolvimento de software, a crise sempre foi pela escassez da mão de obra qualificada. 
Com o surgimento de novos produtos digitas, a carreira dos profissionais de TIC tem 
ganhado novos impulsos. Segundo a Page Personnel, consultoria de recursos humanos 
especializada em profissionais de TIC, os profissionais de desenvolvimento de software, 
de gestão de projetos e de infraestrutura estão entre os mais procurados pelas empresas 
do setor. De acordo com o site CIO, o profissional de desenvolvimento de software ocupou 
o topo dos 9 profissionais de TI mais demandados no Brasil em 2019.
Com a evolução do software, inúmeras oportunidades têm surgido. Com ferramentas, 
modelos e processos apoiando o seu desenvolvimento, o software – mundialmente 
falando – tem se tornado um produto cada vez mais demandado. No entanto, é necessário 
lembrar-se de que nem sempre foi assim! 
No encontro de hoje, vamos aprender sobre a história da evolução do software, um 
produto que está em ascensão gerando diversas oportunidades para a área de TIC.
No contexto atual, diversas são as ferramentas que apoiam o desenvolvimento de 
software. São ferramentas integradas que não só facilitam o trabalho de programação 
de código, criando um ambiente agradável para a produção, como também organizam o 
processo de desenvolvimento de sistemas.
Contudo, no princípio do processamento de dados, o hardware, que é a parte física 
do computador, não continha programas instalados e a sua operação ocorria de forma 
manual. Não havia programas de software para a sua operação, portanto, tudo era 
operado fisicamente. O primeiro computador, ENIAC, era operado manualmente sempre 
que uma tarefa diferente fosse executada.
A criação do EDVAC, por John Von Neumann, em 1945, e o Mark I, criado pela 
Universidade de Harvard, foram de fundamental importância na história da evolução 
do software, pois ao contrário do antecessor, ENIAC – que possuia em torno de 18 mil 
válvulas para o seu funcionamento –, eram computadores com capacidade de armazenar 
programas. Alguns anos mais tarde, esses programas receberam a denominação de 
Software. Foi o cientista americano John Wilder Tukey quem usou o termo software pela 
primeira vez, em 1958. Tukey também foi responsável pelo termo “bit” para se referenciar 
a “dígito binário”.
Vale destacar que antes do ano de 1958, mais especificamente na década 40, cada 
programa era executado isoladamente e com total controle do computador. Existia um 
trabalho árduo para o desenvolvedor que precisava prever tudo de forma minuciosa, 
considerando as entradas de carga do programa em memória, o mapeamento dos 
periféricos de entrada para busca de dados e o envio de dados para os periféricos de 
saída. Já na década de 50, temos a segunda geração da computação moderna, período 
que vai de 1955 até 1965. A programação em batch – conjunto de comandos executados 
em lote, sequencialmente – estava em alta, e surgiu o conceito de sistema operacional, 
que foi de fundamental importância para o computador IBM 701, operado por cartões 
perfurados e fitas magnéticas.
Também no ano de 1965, a IBM lançou o sistema operacional OS/360, com 
compartilhamento de tempo e excelente suporte a discos. Nesse mesmo ano, em um 
projeto envolvendo o Instituto de Tecnologia de Massachusetts (MIT), a General Electric 
(GE) e a Bell Labs, foi criado o sistema operacional Multics, que influenciou novos sistemas 
durante décadas.
Não podemos deixar de lembrar que na década de 60 houve a crise do software, 
pois conforme estudamos na unidade anterior, as entregas dos softwares atrasavam, os 
que eram produzidos não entregavam as funcionalidades que os usuários necessitavam, 
custavam mais que o esperado e não eram confiáveis. Começava a existir uma alta 
demanda no desenvolvimento de sistemas, os profissionais de tecnologia se deparavam 
com a complexidade dos problemas a serem resolvidos e, somado a tudo isso, não havia 
técnicas definidas para o desenvolvimento que garantissem o funcionamento adequado 
das soluções.
No ano de 1981, a Microsoft lançou o seu Sistema Operacional (SO) MS-DOS que, 
na verdade, havia sido adquirido da Seattle Computer Products, em 1980. Em 1984, a 
Apple lançou o SO Macintosh OS 1.0, o primeiro a ter uma interface. A Microsoft, no ano 
de 1985, lançou o Windows 1.0, seu primeiro SO com interface gráfica. No ano de 1987,a IBM e a Microsoft apresentam o OS/2, um sistema multitarefa destinado a substituir 
o MS-DOS e o Windows. Em 1991, Linus Torvalds, um estudante de graduação finlandês, 
lançou na rede Usenet o núcleo 0.01 do Linux, que logo foi adotado por centenas de 
programadores ao redor do mundo. 
O ano de 1993 é marcado por inovações, de um lado temos a Microsoft com o 
Windows NT, o primeiro SO 32 bits, e de outro, o lançamento do SO UNIX de código aberto. 
Em 1995, a Microsoft lançou o Windows 95, com uma interface totalmente inovadora. Em 
2001, temos a Microsoft com o Windows XP e a Apple com o MacOS X. Os Sistemas 
Operacionais da Microsoft mantiveram um padrão que vinha desde o Windows 95. O 
Windows 8, lançado em 2012, apresentava um design minimalista que não foi bem aceito 
pelos usuários. O sistema operacional sucessor ao Windows 8.1, até os atuais, manteve 
as características dos SOs anteriores à versão do 8.0, caracterizada sempre pelo botão 
iniciar que não tinha na versão do SO Windows 8.0. 
A evolução dos sistemas operacionais foi de fundamental importância para o 
desenvolvimento da engenharia de software, pois associado a eles, diversas linguagens 
de programação foram implementadas. Quando a interface era caractere, a linguagem 
de programação COBOL, ainda usada no segmento de sistemas bancários, foi por muitos 
anos a escolhida pelos desenvolvedores de sistemas comerciais. Com o surgimento da 
interface gráfica, sugiram opções como o Visual Objects, o Visual Basic, o Visual FoxPro 
(descontinuado em 2015), o Delphi, entre outras.
Se antigamente o desenvolvimento de aplicações para software limitava-se apenas 
à tela de um computador desktop, hoje, as aplicações têm uma grande variedade de 
dispositivos, tais como tablets, celulares, painéis etc.
São mais oportunidades surgindo para os profissionais de TIC numa área – engenharia 
de software – que não para de evoluir. Se na década de 60 houve a crise do software, 
existe a possibilidade – considerando a grande demanda de soluções – da crise pela mão 
de obra de desenvolvimento de software.
Concluímos aqui o conteúdo sobre a história da evolução do software. Onde você 
conheceu alguns marcos da história da área de Tecnologia da Informação e Comunicação 
(TIC).
Para complementar o seu estudo e aprendizado, continue com pesquisas e leituras 
complementares sobre a temática.
Bons estudos e até o nosso próximo encontro!
Referências da unidade:
9 profissionais de TI mais demandados no Brasil em 2019. CIO, 2018. Disponível 
em: https://bit.ly/3iwfQ30. Acesso em: 18 fev. 2020.
INTRODUÇÃO
Olá, aluno(a)! 
Você já parou para pensar em como um software é desenvolvido?
Se considerarmos todo o processo de criação de um produto de software, desde 
a concepção da ideia – ou necessidade – até a sua entrega, muitas são as etapas e 
pessoas envolvidas nesse processo.
Softwares são concebidos desde a década de 50, mas foi na década de 60 que 
começou a se discutir e criar modelos de processos voltados especificamente para o 
desenvolvimento de software.
O produto de software – estamos nos referindo ao sistema, à aplicação e ao 
programa – é complexo, não é algo palpável, é lógico, sua matéria-prima são trechos, 
dezenas, milhares (a depender da complexidade da solução que está sendo criada) de 
linhas de código de programação escritos numa determinada linguagem. 
Por ser algo lógico, fica difícil para as pessoas compreenderem o que será entregue. 
Ao contrário de áreas como a engenharia civil, em que o produto a ser entregue (casas, 
prédios, estradas, pontes etc.) é de fácil visualização, o software é mais difícil, pois as 
pessoas têm dificuldades em explicar suas necessidades, manifestar suas expectativas e 
deixar claro o que esperam.
Neste conteúdo, dedicaremos nossos estudos para conhecer os principais processos 
de desenvolvimento de software que ajudam na especificação do que deve ser produzido, 
garantindo assim que o produto atenda às necessidades e às expectativas de quem o 
está solicitando.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE:
ESTRUTURA E ORGANIZAÇÃO
Se durante o desenvolvimento de um software considerarmos a complexidade para 
a sua criação, torna-se imprescindível a utilização de um processo para apoiar a execução 
dos trabalhos.
É comum que mudanças ocorram durante a execução das atividades. Com o passar 
do tempo, e na medida em que as reuniões vão sendo realizadas, o cliente passa a entender 
melhor aquilo que será entregue e novas funcionalidades vão sendo requisitadas.
Fazendo uma analogia com a construção civil, antigamente as pessoas tinham de se 
conformar com o layout proposto pela empresa responsável pelo empreendimento. Hoje, 
mudanças podem ser feitas, mas somente no momento em que o projeto de engenharia 
ainda estiver na “planta”, ou seja, quando as obras de construção ainda não começaram. 
Contudo, no caso de projetos de software, ao contrário dos projetos de construção civil, 
as mudanças são do início ao fim. É por essa razão que as empresas produtoras de 
software estão investindo cada vez mais em processos de desenvolvimento.
Em um processo de desenvolvimento de software existem diversas atividades 
relacionadas que são necessárias para a construção de um produto de software. 
Para Sommerville (2011), existem muitos processos de software diferentes, mas 
todos devem incluir quatro atividades fundamentais para a engenharia de software:
1. Especificação de software – A funcionalidade do software e as restrições 
ao seu funcionamento devem ser definidas.
2. Projeto e implementação de software – O software deve ser produzido 
para atender às especificações.
3. Validação de software – O software deve ser validado para garantir que 
atenda às demandas do cliente.
4. Evolução de software - O software deve evoluir para atender às 
necessidades de mudança dos clientes.
Desde o levantamento de requisitos até a liberação da solução de sistema para 
o cliente, existirão diversas atividades. Essas atividades variam em levantamento das 
necessidades (requisitos), análise de sistemas (diagramas de classes e casos de uso), 
desenvolvimento de códigos e testes, além de verificação e validação do produto. Existem 
também as atividades de projetos (plano do projeto), como planejamento, execução, 
monitoramento e controle. 
Um software pode ser desenvolvido de várias formas, e dentro da Engenharia de 
Software existem sugestões de modelos que veremos a seguir, começando pelo modelo 
de desenvolvimento em cascata!
Figura 1: Exemplo de desenvolvimento
Fonte: Elaborado pelo autor
O modelo em cascata considera as atividades de especificação, desenvolvimento, 
validação e evolução, e representa cada uma delas como fases distintas, como: 
especificação de requisitos, projeto de software, implementação, teste, e assim por 
diante. O nome cascata ocorre em razão do encadeamento e da sequência entre uma 
fase e outra, ou seja, trata-se de um ciclo de vida de software. 
Os estágios do modelo representam as atividades de desenvolvimento, como 
“Definição de Requisitos”, “Projeto de Sistema e Software”, “Implementação e Teste 
Unitário”, “Integração e Teste de Sistema” e “Operação e Manutenção”. Em teoria, você 
só pode ir para o estágio seguinte quando concluir o anterior, pois um estágio só começa 
quando o outro termina. Na prática, existe a sobreposição desses estágios. Isso acontece 
porque durante o projeto, os problemas com os requisitos são identificados, durante 
a codificação, os problemas de projeto são encontrados, e assim por diante. Logo, o 
processo de software não é algo linear, mas o feedback de uma fase para outra.
Figura 2: Exemplo de desenvolvimento
Fonte: Elaborado pelo autor
Uma segunda opção de processo para desenvolvimento de software é o incremental. 
Esse modelo considera a ideia de desenvolver uma implementação inicial, expô-la aos 
comentários dos usuários e continuar por meio da criação de váriasversões até que um 
sistema adequado seja desenvolvido. Em vez de entregar todo o sistema ao cliente, a 
entrega ocorre por partes. Essa alternativa pode ser algo vantajoso para ambos os lados, 
pois o cliente recebe mais rápido a solução – ainda que em partes – e no caso de erros, 
será mais rápida a correção, pois há um espaço menor de tempo entre a produção, o teste 
e a entrega. Muitas empresas desenvolvedoras de software estão optando pelo modelo 
incremental devido a essa vantagem.
Figura 3: Exemplo de desenvolvimento
Fonte: Elaborado pelo autor
De uma maneira em geral, a maioria dos projetos de software acaba tendo algum 
reuso. Isso acontece porque as pessoas envolvidas no projeto sabem de projetos ou 
códigos semelhantes que podem atender a uma necessidade do projeto atual. O modelo 
de processo orientado a reuso é uma alternativa de desenvolvimento que busca fazer as 
modificações necessárias de sistemas já existentes, incorporando-as ao sistema que está 
sendo produzido. Um modelo de processo geral de desenvolvimento com base em reuso 
é formado pelos seguintes estágios:
1. Análise de componentes - Etapa em que é feita uma busca por 
componentes para implementar essa especificação;
2. Modificação de requisitos - Os requisitos são analisados com informações 
sobre os componentes que foram descobertos e, em seguida, serão modificados 
para refletir os componentes disponíveis. 
3. Projeto do sistema com reuso - Estágio onde o framework do sistema é 
projetado ou algo existente é reusado.
4. Desenvolvimento e integração - Software que não pode ser adquirido 
externamente é desenvolvido, e os componentes são integrados para criar o 
sistema.
Vale destacar que o reuso ocorre independentemente do processo de desenvolvimento 
que a empresa esteja aditando. Os processos de desenvolvimento de software com foco 
no reuso tornaram-se amplamente usados.
Figura 4: Exemplo de desenvolvimento
Fonte: Elaborado pelo autor
Para que um projeto de software tenha sucesso, torna-se imprescindível que suas 
funcionalidades sejam identificadas. A especificação de software ou engenharia de 
requisitos é o processo que ajuda a compreender a definição dos serviços, os requisitados 
do sistema e a identificação de restrições. Esse é um estágio crítico ao processo de 
software. Equívocos e erros nessa fase irão gerar problemas no projeto e na implementação 
do sistema. 
É importante destacar aqui que o processo de engenharia de requisitos busca 
produzir um documento de requisitos acordados que especifica um sistema que satisfaz 
os requisitos das partes interessadas (stakeholders). Existem quatro atividades principais 
do processo de engenharia de requisitos:
1. Estudo de viabilidade - É feita uma estimativa para satisfazer as 
necessidades do usuário identificado. O estudo considera se o sistema proposto 
será rentável ao negócio e se é possível desenvolve-lo;
2. Elicitação e análise de requisitos - Etapa de derivação dos requisitos do 
sistema. Pode envolver o desenvolvimento de um ou mais modelos de protótipos 
que ajudam a entender o sistema a ser desenvolvido;
3. Especificação de requisitos - Atividade que traduz as informações obtidas 
durante a atividade de análise em um documento que defina um conjunto de 
requisitos; 
4. Validação de requisitos - Verifica os requisitos quanto a realismo, 
consistência e completude. Durante esse processo, erros são descobertos e 
modificações para correção dos problemas são implementadas. 
As atividades no processo de requisitos não são feitas em apenas uma sequência, 
pois elas continuam durante a definição e a especificação. Em razão da compressão que o 
cliente vai adquirindo, novos requisitos surgem durante o processo, portanto, as atividades 
de análise, a definição e a especificação são intercaladas. De acordo com Sommerville 
(2011), nos métodos ágeis, como extreme programming, os requisitos são desenvolvidos de 
forma incremental, de acordo com as prioridades do usuário, e a elicitação de requisitos 
é feita pelos usuários que integram a equipe de desenvolvimento.
Os processos de desenvolvimento de software não se limitam aos que foram 
apresentados anteriormente. Esses são apenas os mais comuns utilizados pelas empresas. 
A depender do segmento que está produzindo o software, poderão existir modelos 
especializados para atender a necessidade de desenvolvimento.
Dificilmente uma empresa adotará um único modelo, e sim uma combinação deles. 
Num estágio inicial para desenvolvimento de um novo produto, a empresa iniciará com 
a especificação de software ou a engenharia de requisitos. Cumprida essa etapa, ela 
poderá adotar o modelo incremental para desenvolver uma implementação inicial e, na 
medida em que a compreensão for aumentando associada ao entendimento do produto 
que será entregue, será possível mesclar com o modelo em cascata, permitindo-se um 
desenvolvimento sequencial, em etapas. A depender da empresa, no caso de já haver a 
experiência de desenvolvimento de muitos sistemas, ela ainda poderá recorrer ao reuso.
Daí vem a importância de você, aluno, conhecer vários modelos para o desenvolvimento 
de software, pois dependendo da situação, um poderá ser mais aplicável ou vantajoso 
que outro.
Ufa! Concluímos nossa leitura sobre o processo de desenvolvimento de software 
considerando a sua estrutura e organização. Perceba que a Engenharia de Software 
apresentou muitas alternativas e detalhes sobre o processo de desenvolvimento de 
software, e será assim para as outras áreas cobertas por essa disciplina, que tem como 
característica essa riqueza de informações.
Como de costume – e sem perder a prática – para dar continuidade e profundidade 
a construção do seu conhecimento sobre o assunto, faça pesquisas e busque por leituras 
complementares.
Um grande abraço e até um próximo encontro!
Referências da unidade:
PRESSMAN, R. S. Engenharia de software: Uma Abordagem Profissional. 8. ed. 
São Paulo: AMGH Editora Ltda, 2016.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
INTRODUÇÃO
Olá, aluno(a)! 
Neste conteúdo, estudaremos as etapas do processo de desenvolvimento de 
software!
Antes que um software possa ser utilizado, ele passa por diversas etapas até que 
finalmente tenha suas funcionalidades implementadas e disponibilizadas para uso. Fazer 
ou ignorar uma ou mais dessas etapas impactará diretamente na qualidade do aplicativo 
de software. 
Qualquer empresa que busca organizar sua rotina de atividades com a utilização 
de práticas orientadas por processos está preocupada com a melhoria dos seus serviços. 
As práticas de processo de software objetivam alcançar resultados satisfatórios de 
qualidade do produto – a aplicação de software – entregando dentro do prazo e do 
orçamento previsto.
DESENVOLVIMENTO DE SOFTWARE: ORGANIZAÇÃO E 
FERRAMENTAS
O processo de desenvolvimento de software pode ser definido como um conjunto 
de passos e atividades ordenadas para atingir um resultado – a entrega do produto 
de software. São etapas que envolvem atividades, restrições, recursos que podem ser 
financeiros, pessoas e insumos (ferramentas de apoio, computadores, servidores etc.).
Existem diversas abordagens, práticas e orientações voltadas para o processo 
de desenvolvimento de software. Algumas mais simples, e outras envolvendo um grau 
maior de complexidade e sofisticação. A escolha dependerá do contexto da empresa 
produtora de software e de variáveis, como quantidade de pessoas (analistas de 
sistemas, desenvolvedores, testadores e gerentes de projetos), segmento do produto, 
cliente e criticidade do negócio, que influenciarão na escolha da abordagem do processo 
de desenvolvimento de software.
Independente do modelo de processo adotado, todos eles tenderão a ter 
características como especificação, projeto e implementação, validação e evolução. 
O termo especificação pode ser interpretado de diferentes maneiras. Para algumaspessoas, especificação significa um documento escrito, enquanto para outras, pode ser 
gráficos e modelo matemático, no entanto, para o desenvolvedor, a especificação pode 
ter o sentido de casos de uso (use case). Segundo Sommerville (2011), a especificação 
de requisitos é um processo de compreensão e definição dos serviços requisitados do 
sistema e a identificação de restrições relativas à operação e ao desenvolvimento do 
sistema. Sommerville (2011) sugere (Figura 1) quatro processos para a especificação de 
requisitos:
• Estudo de viabilidade - Estimativa para avaliar se o sistema proposto 
será rentável a partir do ponto de vista de negócio;
• Elicitação e Análise de Requisitos – São levantados os requisitos do 
sistema por meio da observação, da análise de sistemas existentes e das 
reuniões de discussões com os potenciais usuários e compradores;
• Especificação de requisitos - Traduz as informações obtidas na etapa 
de análise em um documento de requisitos. Os requisitos podem ser do tipo 
usuário, que são declarações abstratas dos requisitos do sistema para o cliente, 
e requisitos de sistema, que são uma descrição mais detalhada da funcionalidade 
a ser provida;
• A validação de requisitos - Verifica os requisitos quanto ao realismo, à 
consistência e à completude.
Figura 1: Os requisitos da engenharia de processos
Fonte: Sommerville (2011)
A formalidade e o formato de uma especificação variam de acordo com o tamanho 
e a complexidade do software a ser desenvolvido.
O projeto e a implementação formam o processo que literalmente converte 
aquilo que foi especificado em um sistema executável. É nessa etapa que acontece o 
desenvolvimento e a programação propriamente dita. As atividades podem variar, tudo 
depende do tipo de sistema a ser desenvolvido. A Figura 2 mostra as atividades que 
podem ser parte do processo de sistemas de informação:
• Projeto de arquitetura - Identifica a estrutura geral do sistema, os 
componentes principais (subsistemas ou módulos), relacionamentos e como 
ocorre a distribuição;
• Projeto de interface - Define as interfaces entre os componentes do 
sistema, o reaproveitamento e o desenvolvimento simultâneo;
• Projeto de componente - É a projeção do funcionamento de cada 
componente do sistema. Pode ser uma funcionalidade a ser implementada ou 
uma lista de alterações a serem feitas em um componente de reuso;
• Projeto de banco de dados - Projeção das estruturas de dados do sistema 
e como eles devem ser representados em um banco de dados. 
Figura 2: Modelo geral do processo de projeto
Fonte: Sommerville (2011)
A validação do software – também comumente chamada de verificação e validação 
(V&V) – objetiva mostrar que a solução de software se adequa às necessidades do cliente. 
É aqui que ocorrem os testes e as simulações para garantir a validação do produto. A 
validação também pode envolver processos de verificação, como inspeções e revisões, em 
cada estágio do processo de software, desde a definição dos requisitos de usuários até 
o desenvolvimento do programa.
Poderão existir estágios e processos de testes (Figura 3). Os mais comuns são:
• Testes de desenvolvimento - Os componentes do sistema são testados 
pelas mesmas pessoas que o desenvolveram. Cada componente é testado de 
forma independente, separado dos outros;
• Testes de sistema - Enquanto o teste de desenvolvimento é isolado, os 
de sistema são integrados. Nessa etapa, existe a preocupação de encontrar 
erros oriundos das interações – interfaces – entre os componentes. Também visa 
mostrar que o sistema satisfaz seus requisitos funcionais e não funcionais, bem 
como testar as propriedades emergentes do sistema;
• Testes de aceitação - É o estágio final para que o sistema seja aceito 
e liberado para uso. Os testes de aceitação devem ser realizados com dados 
fornecidos pelo cliente. Não será possível garantir a sua validade se os dados 
se limitarem a simulações que considerem apenas dados oriundos dos testes 
simulados.
Figura 3: Fases de testes de um processo de software dirigido a planos
Fonte: Sommerville (2011)
As etapas de especificação, de projeto e implementação e de validação são 
fundamentais para gerar a primeira versão do software. Contudo, devemos lembrar que 
a solução passará por mudanças e alterações, em outras palavras, estamos tratando da 
evolução do software. 
Pressman (2016) afirma que a evolução de um projeto de software é um processo 
contínuo que já atinge mais de seis décadas. Para ele, a evolução de produtos e sistemas 
baseados em computador é uma das mais importantes tecnologias no cenário mundial. 
Já Sommerville (2011) (Figura 4), diz que a flexibilidade dos sistemas de software é uma 
das principais razões pelas quais os softwares vêm sendo, cada vez mais, incorporados 
em sistemas grandes e complexos.
Figura 4: Evolução do sistema
Fonte: Sommerville (2011)
Na história do software, sempre houve uma separação entre a etapa de 
desenvolvimento, a de evolução do software e a de manutenção da solução, que algumas 
empresas chamam de sustentação. O desenvolvimento do software é um ciclo criativo em 
que o sistema é desenvolvido e a solução “nasce”. Ocorre apenas uma vez! Depois disso, 
começa a fase de manutenção do software, que é extensa e depende da utilidade do 
software – uma solução de CRM – que pode ter várias repetições do ciclo de manutenção, 
podendo tornar essa fase um processo desinteressante. Embora os custos de manutenção 
possam vir a ser mais altos que os custos iniciais de desenvolvimento, os processos de 
manutenção são, em alguns casos, menos desafiadores do que o desenvolvimento da 
solução original.
Para Sommerville (2011), a distinção entre o desenvolvimento e a manutenção é 
cada vez mais irrelevante. Poucos sistemas de software são totalmente novos, e faz muito 
mais sentido ver o desenvolvimento e a manutenção como processos contínuos. Em vez 
de dois processos separados, é mais realista ver a engenharia de software como um 
processo evolutivo (Figura 4), no qual o software é constantemente alterado durante seu 
período de vida em resposta às mudanças de requisitos e às necessidades do cliente.
Toda nova solução de software passará pelas etapas de especificação, projeto e 
implementação e validação. Após isso, entrará num ciclo de evolução. Essa última, a mais 
longa de todas, pois existirão evoluções de tecnologia, alterações nas leis e aspectos 
jurídicos que a solução de software precisará se adaptar para responder às mudanças e 
às necessidades do cliente. Lembre-se de que em projetos de software, as mudanças são 
inevitáveis.
Compreender cada uma dessas etapas e a sua importância para o desenvolvimento 
de software é fundamental para a criação de software com alto padrão de qualidade. 
Uma etapa de validação fraca, com poucos testes, considerando dados apenas de 
desenvolvimento e sistema, poderá fazer com que um software defeituoso chegue até o 
cliente. Ganhar tempo ao custo do comprometimento de etapas como a especificação, 
projeto e implementação, poderá gerar uma solução que não atende às expectativas do 
cliente.
Cada uma dessas etapas tem o seu valor e a sua contribuição para o sucesso do 
software. Como dito anteriormente, no início dos estudos dessa unidade, existem diversas 
abordagens, práticas e orientações voltadas para o processo de desenvolvimento de 
software. A escolha dependerá do contexto da empresa, mas a equipe deve garantir que 
os processos sejam seguidos para que o resultado seja um software com altos padrões 
de qualidade.
Muito bem, concluímos aqui os estudos sobre o processo de desenvolvimento de 
software considerando a sua organização. É importante sempre que você complemente 
os seus estudos com pesquisas e leituras complementares.
Bons estudos e até um próximo encontro!
Referências da unidade:
PRESSMAN, R. S. Engenharia de software: Uma Abordagem Profissional. 8. ed. 
São Paulo: AMGH EditoraLtda, 2016.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
INTRODUÇÃO
Neste conteúdo, estudaremos outro aspecto de relevância para o desenvolvimento 
de software: os fluxos dos processos.
Assim como existem propostas de desenvolvimento (cascata, incremental, orientado 
a reuso) e etapas (especificação, projeto e implementação, validação e evolução), existem 
as opções de fluxos de processos, que influenciarão na forma de trabalho das atividades 
de desenvolvimento de software.
É importante que você estudante perceba a quantidade de elementos – processos, 
etapas, fluxos – que existem para dar suporte à criação de uma solução de software. 
Mas qual a razão de tantos recursos assim?
Organização!
Todo esse conjunto de práticas existe para organizar o trabalho na área de engenharia 
de software. O software, por ser algo complexo, está exposto a falhas e problemas que 
podem comprometer o produto. As práticas de desenvolvimento, as etapas e os fluxos de 
processos existem para ajudar na entrega de um produto com altos padrões de qualidade. 
MODELOS DE PROCESSOS DE SOFTWARE. PROCESSO LINEAR X 
PROCESSO EVOLUTIVO. MODELO DE PROCESSO EM CASCATA. 
MODELO DE PROCESSO EVOLUCIONÁRIO
Os modelos de processo foram criados com o objetivo de organizar a área de 
desenvolvimento de software. Esses modelos têm contribuído significativamente com o 
trabalho de engenharia de software e fornecem orientações e boas práticas para as 
equipes de desenvolvimento. 
De uma forma geral – e não apenas para a área de engenharia de software – a adoção 
de processos na rotina de trabalho proporciona estabilidade, controle e organização das 
atividades. A sua ausência pode tornar a execução das atividades bastante caótica, 
pois não haverá organização e cada um fará da maneira que mais for conveniente. Um 
modelo de processo fornece os “passos” necessários para a realização de um trabalho de 
engenharia de software disciplinado. 
Os fluxos de processos existem para ajudar a rotina de trabalho das empresas e 
prover maior eficiência na rotina de trabalho da equipe de desenvolvimento. De acordo 
com o modelo CMMI (2010), iniciativas de melhoria de processo bem-sucedidas devem 
ser condicionadas pelos objetivos estratégicos da organização.
O cumprimento de prazos, a entrega dentro de um orçamento previsto e a qualidade 
do produto fornecido são os melhores indicadores de eficácia e eficiência do processo 
utilizado pela organização.
Um aspecto de grande relevância no desenvolvimento de software são os fluxos de 
processos. Os fluxos de processos lineares em relação ao processo de software descrevem 
como são organizadas as atividades, as ações e as tarefas que ocorrem dentro de cada 
atividade em relação à sequência e ao planejamento de tempo (Figura 1).
Figura 1: Fluxo de processos linear
Fonte: Pressman (2016)
Nesse modelo, o fluxo de atividades é executado em sequência, começando com a 
comunicação e terminando com a entrega (Figura 1). Já em um fluxo de processo iterativo 
(Figura 2), existe a repetição de uma ou mais atividades antes de prosseguir para a 
seguinte. 
Figura 2: Fluxo de processos iterativo
Fonte: Pressman (2016)
Um fluxo de processos evolucionário executa as atividades de forma “circular”. Cada 
volta produz uma versão mais completa do software (Figura 3). 
Figura 3: Fluxo de processos circular
Fonte: Pressman (2016)
Um fluxo de processos paralelo executa uma ou mais atividades em paralelo a 
outras, conforme apresentado na Figura 4.
Figura 4: Fluxo de processos em paralelo
Fonte: Pressman (2016)
O modelo de desenvolvimento em cascata, algumas vezes chamado de ciclo de vida 
clássico, sugere uma abordagem de fluxo de processos linear para o desenvolvimento 
de software, que inicia com a especificação dos requisitos, avança pelas fases de 
planejamento, modelagem, construção e disponibilização, chegando na etapa do suporte 
contínuo do software. 
Já o modelo incremental, em que os fluxos das atividades são intercalados, e não 
separados, existe um rápido feedback entre todas as tarefas, e vimos também o modelo 
orientado a reuso, em que existe um aproveitamento de códigos que podem atender a 
uma necessidade do projeto atual.
Sugiro, neste momento, aprofundarmos nossos conhecimentos sobre o modelo espiral 
(Figura 5), que é uma abordagem para o desenvolvimento de sistemas e de software em 
larga escala. Ao contrário do modelo em cascata, em que o fluxo de processo é linear, o 
modelo espiral combinará os fluxos de processos.
Figura 5: Modelo em espiral de processo de software de Boehm (©IEEE 1988)
Fonte: Sommerville (2011)
De acordo com Pressman (2016), o modelo espiral, originalmente proposto por 
Barry Boehm, é um modelo de processo de software evolucionário que une a natureza 
iterativa da prototipação aos aspectos sistemáticos e controlados do modelo cascata. 
Tem potencial para o rápido desenvolvimento de versões cada vez mais completas do 
software. 
No modelo espiral, o software é desenvolvido de forma evolucionária, pois a cada 
iteração existe uma evolução do software. Nas primeiras iterações, a versão pode consistir 
em um modelo ou em um protótipo. Já nas iterações posteriores, são produzidas versões 
cada vez mais completas do sistema, que passa pelo processo de engenharia.
Segundo Pressman (2011), o modelo espiral é dividido em um conjunto de atividades 
metodológicas definidas pela equipe de engenharia de software. A equipe de software 
realiza as atividades indicadas por um circuito em torno da espiral (Figura 5), no sentido 
horário, começando pelo seu centro. Os riscos são levados em conta à medida que cada 
revolução é realizada. 
Ao contrário de outros modelos de desenvolvimento, que terminam quando o 
software é entregue, o modelo espiral possibilita uma adaptação que pode ser aplicada 
ao longo da vida da solução de software. No primeiro circuito, podemos ter um “projeto 
mais conceitual”, que começa no centro da espiral e vai se desenvolvendo pelas várias 
iterações até que o desenvolvimento de conceitos seja concluído. Se o conceito for 
um produto final, o processo continua pelas “bordas” da espiral e um novo projeto de 
desenvolvimento de produto se inicia.
O novo produto terá a sua evolução, que passará pelas iterações ao redor da espiral. 
Na sequência, uma volta em torno da espiral pode ser usada para representar um projeto 
de aperfeiçoamento do produto de software. Essa é a lógica de trabalho do modelo 
espiral que permanece em operação e seguirá assim até que a solução do software seja 
retirada de uso, ou até que a empresa encerre as manutenções e as atualizações do 
produto.
Um modelo de processo fornece orientações para o trabalho, define o fluxo de 
atividades e a iteração entre os papéis (analista de requisitos, analista de sistemas, 
desenvolvedor e testador), sugere modelos de artefatos e organiza o trabalho a ser 
desenvolvido.
É normal – e as vezes necessário – que um modelo de processo seja adaptado 
às necessidades da empresa, pois cada organização tem a sua forma de trabalho e, 
consequentemente, as suas particularidades.
Como sempre, deve-se considerar a empresa, o segmento de software por ela 
desenvolvido, o perfil de seus clientes e a criticidade do negócio, a fim de que os fluxos 
de processos possam contribuir para a qualidade do produto entregue.
Concluímos aqui nossos estudos sobre os modelos de processos de software. Para 
complementar o seu aprendizado, faça pesquisas e leituras complementares.
Bons estudos e até um próximo encontro.
Referências da unidade:
PRESSMAN, R. S. Engenharia de software: Uma Abordagem Profissional. 8. ed. 
São Paulo: AMGH Editora Ltda, 2016.
Software Engineering Institute – SEI. “CMMI for Development, Version 1.3”, CMMI-
-DEV V1.3, CMU/SEI 2010-TR-033, Relatório Técnico. Carnegie Mellon University, 
2010.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
EXEMPLOS DE PROCESSODE DESENVOLVIMENTO SOFTWARE. 
MÉTODO ÁGIL X MÉTODO PREDITIVO.
Olá, aluno(a)! 
Nesta leitura, estudaremos métodos ágeis e faremos uma referência ao método 
preditivo. Consideremos que o método preditivo, é o modelo mais formal para o 
desenvolvimento de software.
É bem verdade que o cenário atual exige um modelo ágil para a produção de software, 
mas existirão situações, principalmente aquelas em que os projetos são complexos, em 
que o modelo ágil poderá não ser o mais adequado. Portanto, é importante que você, 
estudante de engenharia de software, conheça os dois modelos para saber se adequar 
em qualquer tipo de situação.
Para Pressman (2016), um modelo de processo preditivo concentra-se em 
estruturar e ordenar o desenvolvimento de software. As atividades e as tarefas ocorrem 
sequencialmente, com diretrizes de progresso definidas. 
O termo “preditivo” é atribuído porque prescreve um conjunto de elementos de 
processo – atividades metodológicas, ações de engenharia de software, tarefas, artefatos, 
garantia da qualidade e mecanismos de controle de mudanças para cada projeto. Cada 
modelo de processo também prescreve um fluxo de processo (também denominado fluxo 
de trabalho) – ou seja, a forma pela qual os elementos do processo estão relacionados.
De acordo com Pressman (2016), os modelos de processo preditivos são, algumas 
vezes, conhecidos como modelos de processo “tradicionais”. Eles definem um conjunto 
prescrito de elementos de processo e um fluxo de trabalho de processo previsível. São 
aplicados há anos e buscam continuamente organizar e estruturar o desenvolvimento 
de software. Existem diversos modelos com diferentes abordagens, mas todos realizam 
o mesmo conjunto de atividades com objetivos genéricos, tais como a comunicação, o 
planejamento, a modelagem, a construção e a disponibilização da solução de software.
O modelo cascata, incremental e evolucionário (modelo espiral) são exemplos de 
processos preditivos de desenvolvimento de software.
No cenário atual, as empresas 
operam em um ambiente global que exige 
mudanças rápidas. Isso faz com que essas 
empresas necessitem responder a novas 
oportunidades em diferentes mercados. 
Os produtos de softwares fazem parte 
das operações de negócios, assim, surge 
a necessidade de que novos softwares 
sejam desenvolvidos num intervalo de 
tempo cada vez menor, pois somente 
dessa forma poderão aproveitar as 
oportunidades e responder às pressões 
dos concorrentes. 
A capacidade de ter um processo 
de desenvolvimento e de entrega rápidos 
são diferenciais e, por assim dizer, um 
requisito crítico para o desenvolvimento 
das soluções de software. Sendo assim, 
empresas que usam métodos preditivos 
passaram a utilizar métodos ágeis para o 
desenvolvimento de software.
Existem diversas abordagens ágeis, o Extreme Programming (XP) é talvez o mais 
conhecido e utilizado dos métodos ágeis. De acordo com Pressman (2016), o nome 
foi cunhado pelo engenheiro de software americano Kent Beck, pois a abordagem foi 
desenvolvida para impulsionar práticas reconhecidamente boas, como o desenvolvimento 
iterativo a níveis “extremos”. Por exemplo, em XP, várias novas versões de um sistema 
podem ser desenvolvidas, integradas e testadas em um único dia, por programadores 
diferentes.
Na abordagem XP (Figura 1), os requisitos de software são tratados como cenários, 
também chamados de estórias do usuário, e são implementados diretamente como uma 
série de tarefas. Uma característica dessa abordagem é o fato dos desenvolvedores 
trabalharem em pares. Os testes são criados para cada tarefa antes de escreverem o 
código. Há um curto intervalo entre as releases (entregas ou lançamentos) do produto de 
software.
Outra abordagem ágil é o método Scrum!
O nome Scrum provém de uma atividade que ocorre durante a partida do jogo de 
rúgbi. Esse método de desenvolvimento ágil de software foi concebido por Jeff Sutherland 
e sua equipe de desenvolvimento no início dos anos 1990.
Segundo Sommerville (2011), os princípios do Scrum são usados para orientar 
as atividades de desenvolvimento dentro de um processo que incorpora as seguintes 
atividades metodológicas: requisitos, análise, projeto, evolução e entrega. Em cada 
atividade metodológica, ocorrem tarefas realizadas dentro de um padrão de processo 
Figura 1: O ciclo de um release em Extreme Programming
Fonte: Pressman (2016)
chamado sprint. O trabalho realizado dentro de um sprint é adaptado ao problema em 
questão, definido e, muitas vezes, modificado em tempo real pela equipe Scrum. 
O Scrum utiliza um conjunto de padrões de processos de software que tem 
demostrado eficácia para projetos com prazos agressivos e requisitos mutáveis. Cada 
um desses padrões de processos define um conjunto de atividades de desenvolvimento:
1. Backlog – É a lista com prioridades dos requisitos ou das funcionalidades 
do projeto que fornecem valor comercial ao cliente;
2. Sprints – São unidades de trabalho solicitadas para atingir um requisito 
estabelecido no registro de trabalho – o backlog – e que precisam ser ajustadas 
dentro de um prazo já fechado – uma janela de tempo – ou time box, que 
tipicamente pode durar até 30 dias.
O número de sprints necessários para cada atividade metodológica varia dependendo 
do tamanho e da complexidade do produto.
Figura 2: Fluxo do processo Scrum
Fonte: Sommerville (2011)
O Método de Desenvolvimento de Sistemas Dinâmicos ou Dynamic Systems 
Development Method (DSDM) é outra abordagem de desenvolvimento de software ágil. O 
DSDM considera o princípio de Pareto – regra do 80-20 – ou seja, 80% de uma aplicação 
pode ser entregue em 20% do tempo que levaria para entregar a aplicação completa. 
Trata-se de um processo de software iterativo, e cada iteração segue a regra dos 80%, 
enquanto os 20% restantes poderão ser concluídos quando outros requisitos do negócio 
forem conhecidos ou alterações tiverem sido solicitadas pelo cliente.
Para Sommerville (2011), os métodos ágeis são métodos de desenvolvimento 
incremental que se concentram em desenvolvimento rápido, releases frequentes da 
solução de software, redução de overheads dos processos e produção de códigos de 
alta qualidade. São métodos que envolvem o cliente diretamente no processo de 
desenvolvimento.
É comum que pessoas e empresas confundam o termo “ágil” com fazer rápido, o que 
é um tremendo equívoco. Os métodos ágeis têm foco no produto e na entrega, e existe 
uma confiança entre fornecer e cliente, o que justifica menos documentação formal. 
“Ágil” também está relacionado com a capacidade de adaptação rápida da equipe às 
mudanças, e existe sim uma disciplina de processo que deve ser seguida para garantir a 
qualidade da entrega do produto de software. 
Na verdade, muitas empresas estão dispostas a trocar a qualidade e o compromisso 
com requisitos do software por uma implantação mais rápida do software. Essas empresas 
operam em um ambiente de mudanças rápidas e, por isso, muitas vezes, é praticamente 
impossível obter um conjunto completo de requisitos de software estável.
Devemos lembrar que o método preditivo é um modelo mais formal e que dependendo 
da complexidade da solução de software a ser desenvolvida, do escopo do projeto e do 
número de pessoas que participam do processo, esse modelo poderá ser o mais indicado 
para o trabalho.
Referências da unidade:
PRESSMAN, R. S. Engenharia de software: Uma Abordagem Profissional. 8. ed. 
São Paulo: AMGH Editora Ltda, 2016.
Software Engineering Institute – SEI. “CMMI for Development, Version 1.3”, CMMI-
-DEV V1.3, CMU/SEI 2010-TR-033, Relatório Técnico. Carnegie Mellon University, 
2010.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
INTRODUÇÃO
Olá, aluno(a)! 
Este material dedica-se ao estudo de um dos itens mais críticos da engenharia de 
software: os requisitos. 
É comum que, ao pensar em requisitos de software pela primeira vez, as pessoassuponham que a engenharia de requisitos não seja difícil, afinal, entende-se que o cliente 
sabe aquilo que quer ou espera de um sistema de computador, não acha? Mas na prática, 
as coisas acontecem não acontecem bem assim!
Clientes têm dificuldades em expressar suas necessidades, e a pessoa responsável 
por entender essas necessidades e levantar os requisitos do sistema pode não perceber 
a dificuldade, ou não mudar a forma de abordagem para buscar compreender aquilo que 
o cliente espera que a solução de software faça, ou deveria fazer.
Perceba que a solução não depende apenas do cliente ou do profissional responsável 
por levantar os requisitos, mas de uma sintonia entre as duas partes, ou seja, o cliente 
conseguir explicar suas necessidades e o profissional de requisitos conseguir captar e 
buscar entender com mais detalhes o que o cliente está precisando e quais são as suas 
expetativas.
O assunto é complexo e não se trata apenas de uma solução técnica, pois há o 
fator humano envolvido, e isso requer alternativas de soluções diferentes. Talvez seja 
esse um dos fatores que torna a engenharia de requisitos um assunto tão vasto e algo 
tão interessante de ser estudado.
O QUE SÃO REQUISITOS DE SOFTWARE
A etapa referente à engenharia de requisitos começa com a concepção, etapa em 
que se define a abrangência e a natureza do problema a ser resolvido. Na sequência, há 
o levantamento de informações, que ajuda os envolvidos a definir o que é necessário e, 
em seguida, temos a etapa de elaboração, em que os requisitos básicos são refinados e 
modificados. 
À medida que as pessoas envolvidas vão definindo o problema, ocorre a negociação, 
em que são estabelecidas as prioridades, o que é essencial e quando deverá ser entregue. 
Finalmente, o problema é especificado e validado para garantir que o seu entendimento 
sobre o problema e o dos envolvidos coincidam. 
Na prática, pelo menos, deveria funcionar assim. No entanto, durante esse processo, 
o entendimento é alterado, pois as pessoas começam a ter uma compreensão melhor da 
solução e mudanças podem ser solicitadas. Mesmo que a especificação do problema ou 
a solução a ser desenvolvida seja identificada, poderão haver muitas discussões entre o 
cliente e o profissional responsável pelo levantamento de requisitos.
Para Pressman (2016), entender os requisitos de um problema está entre as tarefas 
mais difíceis enfrentadas por um engenheiro de software. O autor destaca também que 
é importante entender o que o cliente quer antes de começar a projetar e construir um 
sistema baseado em computador.
A engenharia de requisitos objetiva proporcionar um entendimento escrito do 
problema. Isso pode ser obtido por meio de uma série de artefatos: cenários de uso, listas 
de funções e características, modelos de análise ou uma especificação.
Esses artefatos, gerados pela engenharia de requisitos, são revisados com os 
envolvidos para garantir que aquilo que foi discutido com o cliente seja realmente aquilo 
que ele espera receber. É importante que isso seja tratado de forma minuciosa para que 
as expectativas com a solução de software não sejam frustradas. Pressman (2016) alerta 
para o fato de que mesmo depois de todas as partes terem entrado em acordo, as coisas 
vão mudar e continuarão mudando ao longo do projeto.
Segundo Pressman (2016), a engenharia de requisitos abrange sete tarefas distintas: 
concepção, levantamento, elaboração, negociação, especificação, validação e gestão. 
Algumas dessas tarefas podem ocorrer em paralelo e todas devem ser adaptadas às 
necessidades do projeto.
A concepção é o momento em que o projeto de software é iniciado. Essa tarefa pode 
acontecer de diversas formas, como numa conversa informal ou numa reunião formal de 
alinhamento, não existe regra para isso. De uma forma geral, a concepção pode vir do 
surgimento de uma necessidade do negócio, da descoberta de um novo serviço ou da 
identificação de um mercado em potencial. 
Quando um plano de negócio é definido, ou seja, o tamanho do mercado é 
identificado, uma análise de viabilidade é realizada e uma descrição operacional é gerada. 
Essas informações são de grande ajuda nas discussões com o cliente para se levantar 
os requisitos. Existe aqui uma elicitation, ou seja, uma investigação que busca entender 
os fluxos relevantes da solução, os aspectos técnicos e demais detalhes que ajudem a 
identificar os requisitos do projeto de software.
O levantamento é a etapa em que se deve identificar objetivos 
para o sistema ou produto de software, como as seguintes perguntas: 
O que deve ser obtido? Como o sistema deve atender às 
necessidades? Como o software será utilizado no dia a dia? 
Na teoria, essa tarefa é relativamente simples, contudo, na prática, os futuros 
usuários do sistema poderão ter dificuldades em responder com exatidão as perguntas 
feitas. Uma das justificativas para isso pode ser a dificuldade de se imaginar o software 
funcionando. Lembre-se de que estamos falando de um produto lógico, gerado por meio 
de códigos de programação. Se o produto a ser entregue fosse uma casa, a facilidade de 
visualização ajudaria consideravelmente no levantamento dos requisitos da residência, 
mas estamos falando de um software, logo, a abordagem deve ser diferente. Aqui, a 
experiência e o bom senso do profissional de tecnologia faz muita diferença.
Na etapa de elaboração, aquelas informações que foram obtidas junto ao 
cliente durante a concepção e o levantamento serão agora expandidas e refinadas. 
Nesse momento, existe o desenvolvimento de um modelo de requisitos que identifica 
características, funções e comportamentos referentes ao produto de software. Vale 
destacar que na etapa de elaboração são criados cenários que descrevem como os 
usuários – os atores – vão interagir com o sistema. A quantidade de cenários varia com a 
complexidade da solução.
Com a concepção, o levantamento e 
a elaboração, já haverá transcorrido tempo 
e oportunidades de amadurecimento 
suficientes para que os usuários comecem 
a compreender melhor a solução do 
produto de software. O cliente poderá 
pedir mais do que é possível entregar, 
poderá haver necessidades conflitantes 
e sugestões que fogem ao escopo do 
projeto. É nesse momento que acontece a 
etapa de negociação! 
Nessa etapa, é preciso conciliar 
esses conflitos, portanto, o processo 
de negociação será fundamental. Bons 
argumentos por parte do profissional 
de requisitos, consenso quanto à ordem 
dos requisitos, utilização de abordagens 
iterativas que ajudem na priorização dos 
requisitos e considerações quanto aos 
custos e riscos devem ser considerados 
para que os conflitos sejam tratados de 
modo que cada pessoa envolvida possa 
atingir um nível de satisfação.
Com os conflitos resolvidos, vamos para a etapa de especificação. Pressman (2016) 
afirma que no contexto de sistemas baseados em computador (e software), o termo 
especificação assume diferentes significados para diferentes pessoas. Especificação pode 
ser um documento por escrito, um conjunto de modelos gráficos, um modelo matemático 
formal, um conjunto de cenários de uso, um protótipo ou qualquer combinação dos fatores 
citados. 
De acordo com Pressman (2016), para sistemas grandes, um documento escrito, 
combinando descrições em linguagem natural e modelos gráficos, pode ser a melhor 
abordagem. Entretanto, talvez sejam necessários apenas cenários de uso para produtos 
ou sistemas menores que residam em ambientes técnicos bem compreendidos.
A etapa de validação é o momento em que os artefatos produzidos pela engenharia 
de requisitos terão sua qualidade avaliada. Nessa etapa, examina-se a especificação 
como forma de garantir que os requisitos do produto tenham sido declarados de forma 
não ambígua. A validação busca eliminar inconsistências e omissões, além de detectar e 
corrigir erros. Para Pressman (2016), o principal mecanismo de validaçãode requisitos é 
a revisão técnica.
A gestão de requisitos é um conjunto de atividades que identifica, controla e 
acompanha as necessidades e suas mudanças à medida que o projeto de software evolui. 
Com o tempo – e isso é quase certo de acontecer – os requisitos podem mudar e, por isso, 
torna-se necessária uma gestão para controlar essas mudanças.
Pressman (2016) sugere sete tarefas distintas para a engenharia de requisitos. 
Somado a isso, podemos acrescentar técnicas como brainstorm, delphi, fóruns de 
discussão, shadowing, mapas mentais e, ainda assim, algum requisito-chave pode passar 
desapercebido pela equipe.
Conforme comentamos no início de nosso estudo, o assunto é complexo e não se 
trata apenas de uma solução técnica, pois há o fator humano envolvido e isso requer 
alternativas de soluções diferentes. Talvez seja esse um dos fatores que torna a engenharia 
de requisitos um assunto tão vasto e algo tão interessante de se aprender.
Caro(o) aluno(a), você chegou ao final desse conteúdo, parabéns! Nele, você se 
aprofundou nos detalhes sobre os Requisitos de Software e entendeu a importância dos 
requisitos para um produto de software. Para complementar o seu aprendizado, continue 
com pesquisas e leituras complementares.
Até breve!
Referências da unidade:
PRESSMAN, R. S. Engenharia de software: Uma Abordagem Profissional. 8. ed. 
São Paulo: AMGH Editora Ltda, 2016.
Software Engineering Institute – SEI. “CMMI for Development, Version 1.3”, CMMI-
-DEV V1.3, CMU/SEI 2010-TR-033, Relatório Técnico. Carnegie Mellon University, 
2010.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
A IMPORTÂNCIA E CLASSIFICAÇÕES: REQUISITO FUNCIONAL E 
REQUISITO NÃO-FUNCIONAL, REQUISITO NÃO-FUNCIONAL DE 
PRODUTO, ORGANIZACIONAL E EXTERNO
Olá, aluno(a)! 
Neste material trataremos sobre os requisitos de software, na tangente da 
classificação dos requisitos.
A capacidade de realizar uma boa avaliação de requisitos impactará diretamente 
na qualidade do produto de software. Por esse motivo, a engenharia de requisitos é algo 
completamente relevante para o desenvolvimento de sistemas.
De acordo com Sommerville (2011), os requisitos de um sistema são as descrições 
do que o sistema deve fazer, os serviços oferecidos e as restrições do seu funcionamento. 
Esses requisitos refletem as necessidades dos clientes para um sistema que serve a uma 
finalidade determinada, como controlar um dispositivo, colocar um pedido ou encontrar 
informações. 
O termo “requisito” não é usado de forma consistente pela indústria de 
software. Há casos em que o requisito é uma declaração abstrata em alto nível, 
um serviço que o sistema deve oferecer, uma restrição do sistema, uma definição 
detalhada e formal de um recurso ou uma função do sistema.
O levantamento de requisitos é crítico para o processo de construção de software. 
Equívocos nessa etapa comprometerão as demais subsequentes. Um dos problemas que 
surgem são as falhas em não fazer uma clara separação entre esses diferentes níveis 
de descrição. É sugerida uma distinção entre “requisitos de usuário” que expressará os 
requisitos abstratos de alto nível e “requisitos de sistema”, que expressará a descrição 
detalhada do que o sistema deve fazer. 
Os requisitos de usuário são declarações escritas numa linguagem natural com 
diagramas que expressam quais serviços a solução de software deverá fornecer a seus 
usuários, enquanto os requisitos de sistema são descrições mais detalhadas das funções 
dos serviços da solução de software. 
O documento de requisitos do sistema, também conhecido por especificação 
funcional, deve orientar com exatidão aquilo que deve ser implementado. Enquanto 
o requisito de usuário contém informações mais em alto nível, o requisito de sistema 
fornece uma informação mais específica sobre serviços e funções do sistema que devem 
ser implementados.
Sommerville (2011) destaca que diferentes níveis de requisitos são úteis, pois eles 
comunicam informações sobre o sistema para diferentes tipos de leitores. Eles precisam 
ser escritos em diferentes níveis de detalhamento, pois, dessa forma, diferentes leitores 
poderão usá-los de diversas maneiras. É importante destacar que os leitores dos 
requisitos de usuário não se preocupam com a forma como o sistema será implementado, 
logo, eles podem não estar interessados nos recursos detalhados do sistema. O mesmo 
não acontece com os leitores dos requisitos de sistema, pois esses precisam saber mais 
detalhadamente o que o sistema fará e como o sistema apoiará os processos de negócios.
Os requisitos de software são classificados como requisitos funcionais e requisitos 
não funcionais. Os requisitos funcionais são as declarações de serviços que o sistema 
deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve 
se comportar em determinadas situações. Em alguns casos, os requisitos funcionais 
também podem explicitar o que o sistema não deve fazer. Em outras palavras, os requisitos 
funcionais de um sistema descrevem o que o sistema deve fazer.
Os requisitos não funcionais referem-se às restrições a serviços ou funções do sistema. 
As restrições podem ser de tempo, processamento ou normas legais. Por exemplo: o sistema 
processa documentos com até 1.000.000 (um milhão de registros). Trata-se de requisitos 
que não estão diretamente relacionados com os serviços oferecidos pelo sistema a seus 
usuários. Eles podem estar relacionados às propriedades, como confiabilidade, tempo de 
resposta e ocupação de área. Eles podem restringir as características do sistema como 
um todo, por exemplo, o desempenho, a proteção e a disponibilidade do sistema. Os 
requisitos não funcionais geralmente são mais críticos que os requisitos funcionais.
A Figura 1 apresenta a visão geral organizada com tipos de requisitos de software.
Figura 1: Visão geral dos tipos de requisitos de software
Fonte: elaborado pelo autor
Os requisitos não funcionais podem ser classificados em três tipos, definidos como:
1. Requisitos de produto – São provenientes das características requeridas 
para o produto de software. Eles especificam ou restringem o comportamento 
do software, como a rapidez com que o sistema deve executar uma consulta ou 
impressão de um relatório;
2. Requisitos organizacionais – São provenientes das organizações que 
desenvolvem o produto de software. Alguns exemplos desses requisitos são: a 
linguagem de programação, o ambiente de desenvolvimento e o processo de 
desenvolvimento que deverá ser seguido;
3. Requisitos externos – Abrangem todos os requisitos que se originam 
dos fatores externos ao sistema e ao seu processo de desenvolvimento, como 
aspectos legais, requisitos reguladores, normas a serem seguidas etc. Um 
sistema voltado para o segmento financeiro, por exemplo, deverá atender a 
exigências de um órgão regulador para essa área, o Banco Central.
É importante que você perceba a extensão e a complexidade desse assunto para o 
desenvolvimento das soluções de software.
Com isso concluímos que o requisito é uma etapa fundamental do processo de 
desenvolvimento de software. Uma informação mal compreendida, o esquecimento de 
um item de relevância para a solução e o levantamento de informações imprecisas são 
fatores que impactam o resultado do produto de software.
Por esses motivos, dedicamos o nosso estudo sobre a importância e os tipos de 
requisitos de software. Não é demais repetir que a capacidade de se realizar uma boa 
avaliação de requisitos impactará diretamente na qualidade do produto de software. Por 
isso, a engenharia de requisitos é algo tão relevante para o desenvolvimento de sistemas.
Para aprofundar seus conhecimentos sobre o assunto, continue nas suas pesquisas 
e leituras complementares. 
Bons estudos e até um próximo encontro!
Referências da unidade:
PRESSMAN, R. S. Engenharia de software: Uma Abordagem Profissional. 8. ed. 
São Paulo: AMGHEditora Ltda, 2016.
Software Engineering Institute – SEI. “CMMI for Development, Version 1.3”, CMMI-
-DEV V1.3, CMU/SEI 2010-TR-033, Relatório Técnico. Carnegie Mellon University, 
2010.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
O QUE SÃO REQUISITOS BEM E MAL DESCRITOS
O que justifica haver tantos problemas com a engenharia de 
requisitos?
Ter um bom conhecimento técnico não é o suficiente para conseguir obter os requisitos 
dos clientes. Nesse processo – o de levantamento dos requisitos – existe uma série de 
fatores não técnicos envolvidos, e um desses, talvez o mais crítico, seja a comunicação!
Imagine uma entrevista em que o profissional de tecnologia 
está num processo de entrevista para levantar os requisitos do 
sistema de software. Esse profissional – que geralmente para essa 
função é o analista de negócios – está tendo dificuldades para 
entender as informações passadas pelo cliente. Para o cliente, não 
está claro o que o sistema deve gerar, quais relatórios devem ser 
produzidos, quais dados devem ser consultados e quais informações 
serão registradas na solução de software. Se esse processo continuar 
dessa forma, com dificuldade de se dizer o que se espera do sistema 
e com dificuldade de se entender o que precisa ser feito, haverá um 
registro de requisitos desorganizado. Mas por que isso acontece?
Os motivos são muitos, como o analista de negócios ter pouca experiência na 
função, não estar claro para o cliente o que precisa ser feito, a existência de precipitação 
por parte do cliente em chamar o profissional, ou a empresa de desenvolvimento, aquilo 
que precisa ser feito estar claro – mas apenas para uma pessoa da equipe ou, por fim, 
analistas e desenvolvedores pressionados por prazos querem começar a desenvolver 
antes do levantamento dos requisitos ter sido concluído! 
Uma das razões por tantos problemas com os requisitos de um software deve-se 
ao fato de se investir pouco tempo para entender aquilo que precisa ser feito. Clientes 
dedicam pouco tempo para debater as necessidades e empresas de solução de software 
reservam pouco tempo para compreender o que precisa ser feito. De uma forma geral, 
investe-se pouco na verificação daquilo que está sendo registrado. O resultado é a 
ausência de uma referência confiável do que precisa realmente ser feito e implementado 
para o produto de software. 
O resultado disso é a necessidade de se realizar outras reuniões para compreender 
melhor o que está sendo solicitado. Como se não bastasse, é comum que os clientes não 
tenham uma compreensão clara do que está sendo solicitado, existe uma vaga noção 
daquilo que precisa ser resolvido.
Requisitos equivocados resultam em software que não gera a solução esperada 
para o cliente. Isso envolve custo de retrabalho, desgaste da equipe e do cliente, 
comprometimento da imagem da empresa que está desenvolvendo o produto e atraso 
nos projetos de ambos os lados – cliente e fornecedor.
Situações como as citadas acima são corriqueiras na área de desenvolvimento de 
sistemas e, apesar das diversas técnicas e ferramentas para a lidar com esse tipo de 
questão, o problema continua a se repetir nos projetos de desenvolvimento de software.
A Figura 1 é um exemplo clássico utilizado para mostrar o processo de desenvolvimento 
do software desde a sua concepção – levantamento de requisitos –, momento em que o 
cliente explica para o analista de negócio (dependendo da empresa pode ser o gerente 
do projeto) o que ele espera e o analista registra o que entendeu, até a entrega do 
produto ao cliente.
Figura 1: Processo de desenvolvimento de software
Fonte: Startup Sorocaba¹
¹Disponível em< https://tinyurl.com/y9kbbb8q>. Acesso em 07/07/20
A engenharia de requisitos deve estabelecer uma ponte entre o demandante (o 
cliente) e o demandando (a empresa que desenvolverá o produto). Na teoria, é simples, 
mas na prática, surgem dúvidas como: 
Onde é o início dessa ponte? Quem define a necessidade do negócio? Quem define 
as restrições? O início dessa ponte ocorre por meio de uma definição mais genérica? 
O mercado tem respondido a isso com a oferta de soluções de aplicativos, técnicas 
e processos. Uma solução que tem surtido efeito é diminuir os ciclos de desenvolvimento 
dos produtos de software. Em vez de buscar compreender o produto como um todo e 
apresentar – após um longo tempo de desenvolvimento – a versão completa da solução 
que demandará diversos ajustes, entrega-se partes menores do produto. Essa prática 
apresenta diversas vantagens, pois em caso de erro, a solução será mais simples, devido 
a menos integrações entre componentes. O intervalo entre aquilo que foi desenvolvido e 
a solução chegar ao cliente é menor, portanto, será mais fácil relembrar o que foi feito. 
A compreensão do cliente evoluirá junto com a solução. Em caso de mudanças e 
implementação de novas funcionalidades, será mais fácil agregar a solução. Em partes 
menores, o gerenciamento será mais fácil, e a compreensão dos requisitos será mais 
precisa e completa.
A área de engenharia de software conta com modelos para avaliar a maturidade 
dos processos. Um deles é o Capability Maturity Model® Integration (CMMI). O CMMI 
é um modelo internacional de maturidade para melhoria de processo, destinado ao 
desenvolvimento de produtos e serviços, e composto pelas melhores práticas associadas 
a atividades de desenvolvimento e de manutenção que cobrem o ciclo de vida do produto 
desde a concepção, até a entrega e manutenção.
A engenharia de requisitos no modelo CMMI é representada por dois processos. O 
primeiro processo, Desenvolvimento de Requisitos, identifica as necessidades do cliente 
e traduz essas necessidades em requisitos de produto. O segundo processo, Gestão 
de Requisitos, assegura que as mudanças ocorridas nos requisitos sejam refletidas em 
planos, atividades e produtos de trabalho do projeto. Esses dois processos mostram a 
relevância do tema – engenharia de requisitos – para esse modelo internacionalmente 
adotado por diversas empresas.
Apesar de haver soluções de ferramentas para levantamento de requisitos do 
produto, modelos e boas práticas de processos, a atividade de se desenvolver um 
documento de requisitos de forma rápida e precisa ainda é um desafio para as equipes 
de desenvolvimento de software.
Concluímos aqui nossos estudos sobre a importância dos requisitos para o 
desenvolvimento de software. Para complementar o seu aprendizado, continue com 
pesquisas e leituras complementares.
Bons estudos!
Referências da unidade:
PRESSMAN, R. S. Engenharia de software: Uma Abordagem Profissional. 8. ed. 
São Paulo: AMGH Editora Ltda, 2016.
Software Engineering Institute – SEI. “CMMI for Development, Version 1.3”, CMMI-
-DEV V1.3, CMU/SEI 2010-TR-033, Relatório Técnico. Carnegie Mellon University, 
2010.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
INTRODUÇÃO
Olá, estudante! Bem-vindo(a). Aprenderemos sobre o Processo Unificado, que é um 
modelo de desenvolvimento de sistemas organizado em fases (Concepção, Elaboração, 
Construção, Transição e Produção), interações - conjuntos de casos de uso – e os 
incrementos.
O Processo Unificado tem como objetivo aproveitar os melhores recursos e 
características dos modelos tradicionais de processo de software sendo assim, um 
complemento fundamental para a evolução do nosso aprendizado.
O PROCESSO UNIFICADO DE SOFTWARE
Segundo Pressman (2016), o Processo Unificado (Unified Process - UP) de 
desenvolvimento de software é o conjunto de atividades necessárias para transformar 
requisitos do usuário em um sistema de software. Para Pressman, o UP de desenvolvimento 
de sistemas combina os ciclos iterativo e incremental para a construção de softwares. É 
fundamental na visão de que o avanço de um projeto deve estar baseado na construção 
de artefatos de software e não apenas em documentação.
O Processo Unificado é um modelo