E3_ENSO

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE
Roque Maitino Neto
E-book 3
Neste E-Book:
INTRODUÇÃO ����������������������������������������������������������� 3
ENGENHARIA DE REQUISITOS ��������������������������� 5
Requisitos de Software �������������������������������������������������������������5
Engenharia de Requisitos ���������������������������������������������������������7
Validação dos Requisitos �������������������������������������������������������22
Arquitetura de Software ����������������������������������������������������������24
Ambientes de desenvolvimento de software ������������������������28
Implantação de Software �������������������������������������������������������30
CONSIDERAÇÕES FINAIS ����������������������������������� 33
REFERÊNCIAS BIBLIOGRÁFICAS & 
CONSULTADAS �������������������������������������������������������34
2
INTRODUÇÃO
Nenhum novo produto é concebido nem criado ao 
acaso� Do seu planejamento até sua disponibilização, 
muitas etapas são cumpridas e a qualidade desse 
produto terá relação direta com a qualidade do pro-
cesso que o criou� Sua efetiva construção é apenas 
uma das etapas do seu processo de criação, e não 
a única nem a primeira, sequer a mais importante� 
Antes que algo ganhe corpo, devem ser criteriosa-
mente definidas as suas funcionalidades, suas ca-
racterísticas, as restrições aplicadas e as demais 
condições para que ele exista e seja adequado ao 
seu propósito� A esse conjunto de elementos damos 
o nome de requisitos�
Conforme o desenvolvimento do nosso conteúdo 
sobre requisitos se dá, você terá a oportunidade de 
conhecer algumas definições sobre requisitos, das 
simples até as mais elaboradas� No entanto, em sua 
essência, requisito será tratado como uma condi-
ção que viabiliza a existência de um produto, e que 
reflete uma funcionalidade ou característica desse 
produto� Sem a determinação e validação criteriosa 
do conjunto dos requisitos de um produto, a chance 
de insucesso no projeto de sua criação será consi-
deravelmente grande�
Essa realidade genérica sobre requisitos também 
vale para a Engenharia de Software e neste módulo 
teremos a oportunidade de discutir suas especificida-
des sob a ótica da Engenharia de Requisitos – nome 
3
que se dá a todas as etapas do percurso trilhado 
pelos requisitos em um projeto de software� E, para 
bem cumprir objetivos desta parte da nossa jornada, 
nosso texto abordará também os principais elemen-
tos da arquitetura de um software, as características 
dos ambientes de desenvolvimento de software e, 
por fim, aspectos próprios de implementações de 
software�
Bons estudos!
4
ENGENHARIA DE 
REQUISITOS
Talvez a forma mais eficiente de se comprovar a 
importância dos requisitos em um processo de de-
senvolvimento de software seja negligenciando o 
tratamento que se deve dispensar a eles� A falta de 
cuidado na coleta dos requisitos, o pouco caso no en-
tendimento do seu real valor e o insuficiente investi-
mento de tempo na sua validação são omissões com 
grande potencial para comprometer o restante do 
projeto, e tornar amargas as lembranças da falta de 
diligência com essa fase tão importante do projeto� É 
justamente para que você não precise compreender 
a relevância dos requisitos da forma mais difícil que 
o abordaremos aqui em detalhes, começando pelas 
suas definições básicas.
Requisitos de Software
De acordo com Wazlawick (2013), os requisitos são 
a expressão mais detalhada sobre aquilo de que o 
usuário ou cliente precisa em termos de um produto 
de software� Eles são, portanto, a essência de um 
sistema, e a base sobre o qual ele será construído� 
Idealmente, nada do que não tenha sido definido 
como requisito (em sentido amplo) deve fazer parte 
do sistema e essa premissa tem sido cada vez mais 
colocada em prática com as metodologias ágeis�
5
Fernandes e Machado (2017) conceituam requisito, 
de modo geral, como qualquer coisa que alguém 
queira� Já no contexto da Engenharia de Software, 
os autores o colocam como propriedades que os 
sistemas (ainda em projeto) devem manifestar quan-
do estiverem desenvolvidos� Em outras palavras, os 
requisitos expressam as necessidades dos usuários 
e as restrições que devem ser consideradas durante 
o desenvolvimento do sistema�
De fato, o termo requisito não possui apenas uma 
definição válida e, além disso, a percepção do seu 
valor pode variar entre cliente, desenvolvedor e de-
mais atores do processo de desenvolvimento� Há, 
no entanto, uma restrição importante sobre seu sig-
nificado, dada por Vazquez e Simões (2016): não se 
pode considerar requisito como sinônimo de docu-
mentação com as especificações de requisitos. A 
documentação – continuam os autores – é fruto da 
necessidade de se registrar os resultados do trabalho 
intelectual realizado sobre os requisitos, para que a 
informação não se perca e possa ser compartilhada 
posteriormente�
Dada a sua importância no contexto do desenvolvi-
mento de sistemas, a área de requisitos tornou-se 
um ramo específico da Engenharia de Software e, 
como tal, ocupa-se com a sistematização das etapas 
de levantamento, análise, especificação e validação 
das propriedades que devem ser apresentadas para 
resolver tarefas relacionadas ao software em de-
senvolvimento� Tais propriedades são comumente 
relacionadas às funcionalidades do produto, mas 
6
estão ligadas também aos objetivos, restrições e 
padrões do sistema�
FIQUE ATENTO
Os requisitos de software expressam as neces-
sidades e restrições colocadas num produto de 
software que contribuem para a solução de algum 
problema do mundo real�
Engenharia de Requisitos
Conforme mencionamos, a consolidação dos con-
ceitos, técnicas e práticas associadas aos requisitos 
é chamada Engenharia de Requisitos, definida por 
Vazquez e Simões (2016) como uma disciplina da 
Engenharia de Software que consiste no uso siste-
mático e repetitivo de técnicas para cobrir atividades 
de obtenção, documentação e manutenção de um 
conjunto de requisitos para software que atendam 
aos objetivos do negócio. Os autores justificam o 
uso do termo “Engenharia” nesse contexto por meio 
da comparação do processamento dos requisitos 
com as etapas de um programa norte-americano de 
desenvolvimento da Ciência entre jovens, chamado 
Engenharia é Elementar� De acordo com esse pro-
grama, o processo geral da Engenharia é ilustrado 
na figura 1.
7
Melhore
Pergunte
Imagine
Planeje
Crie
Figura 1: O processo geral da Engenharia� Fonte: Vazquez 
e Simões (2016)
Mas como, afinal, a Engenharia de Requisitos se re-
laciona com esse processo? Iniciemos a análise pela 
etapa “Pergunte”: nela se busca identificar a natureza 
do problema e as restrições que a ele se aplicam e é 
exatamente assim que o ciclo dos requisitos se inicia� 
Na sequência, a etapa “Imagine” servirá para que se 
levante as alternativas e, entre elas, a melhor solução, 
o que também se relaciona com o segundo passo 
no caminho dos requisitos� Já na etapa “Planeje”, 
os itens relacionados à solução são levantados, ou 
seja, tudo o que servirá para solucionar o problema 
é reunido nesta etapa�
O processo segue seu caminho até a etapa “Crie”, 
na qual os planos devem ser colocados em prática 
e os resultados submetidos a testes, o que também 
é feito com os requisitos na ocasião em que são 
8
validados. Por fim, na etapa “Melhore”, é discutido 
o que funciona, o que não funciona e o que poderia 
ser melhorado� Aqui, haverá sempre a possibilidade 
de se aplicar melhorias no projeto e colocá-lo sob 
teste novamente� Esse ciclo, aplicado à realidade 
dos requisitos, promove o entendimento contínuo 
das necessidades do cliente e habilita a equipe a 
atender seus objetivos de negócio, que são dinâmi-
cos e mutáveis. (VAZQUEZ; SIMÕES, 2016)
Na sequência, trataremos das etapas da Engenharia 
de Requisitos� É necessário registrar que algumas 
fontes da literatura podem divergir em relação a no-
mes, escopo e quantidade de etapas� Será natural 
também que, considerando a metodologia de de-
senvolvimentoem que o conteúdo sobre requisitos 
é desenvolvido, algumas especificidades dessa me-
todologia sejam a causa de alguma divergência com 
o que trataremos adiante�
Levantamento de Requisitos
Para que uma equipe possa atuar sobre os requisitos, 
a primeira tarefa que se impõe é o levantamento des-
ses requisitos. Antes de definirmos essa etapa, cabe 
o registro de que muitos outros termos semelhantes 
são designados para identificá-la: descoberta de re-
quisitos, coleta de requisitos, extração de requisitos, 
aquisição de requisitos ou elicitação de requisitos� 
Esta última, mais comumente usada, constitui uma 
versão brasileira do termo elicit requirements�
De acordo com Vazquez e Simões (2016), esses dife-
rentes termos podem transmitir percepções igualmente 
9
distintas� “Coletar” requisitos pode dar a ideia de que 
bastaria buscá-los em uma prateleira para ter acesso 
a eles� “Adquirir” requisitos pode provocar a impressão 
de que seria necessária uma negociação para obtê-
-los, o que, muitas vezes, é procedente� Já a expressão 
“descobrir” requisitos pode induzir o observador a en-
tender que seria necessário um trabalho investigativo 
para obtê-los, o que também é verdadeiro em muitos 
casos� Usaremos, então, os termos “levantar” e “elicitar” 
requisitos como sinônimos para as nossas finalidades.
Levantar requisitos, portanto, significa adquirir co-
nhecimento sobre o produto a ser construído, sobre 
o ambiente de negócios em que esse produto estará 
inserido e sobre as pessoas que, de uma forma ou 
de outra, serão impactadas pelo projeto� As ações de 
levantamento de requisitos requerem técnicas para 
sua boa execução e que serão abordadas adiante� 
O resultado dessa fase deve ser consolidado em 
documentos que contenham as entrevistas, anota-
ções, observações feitas e tudo o mais que tenha 
registrado o conhecimento levantado� 
Schach (2009) aponta ações que devem dar sentido 
ao trabalho de levantamento de requisitos e a pri-
meira delas é determinar o que o cliente precisa, ao 
invés de o que o cliente quer� Não se trata de uma 
identificação simples e deverá requerer habilidade da 
equipe, já que frequentemente os clientes não sabem 
do que precisam ou têm dificuldade em expressá-lo, 
principalmente no início do projeto� É necessário 
também que o grupo destacado conheça o campo 
de aplicação, ou seja, a área geral em que o software 
10
será aplicado� Um campo de aplicação pode ser o 
setor de indústria metalúrgica, o comércio varejista 
e o setor acadêmico, entre tantos outros�
Da mesma forma que a aquisição de conhecimento 
sobre um determinado assunto pode se dar de várias 
formas, o levantamento dos requisitos também pode 
(e deve) ser executado com métodos distintos� É 
necessário que o responsável por essa atividade te-
nha em mente que levantar requisitos envolve ações 
essencialmente humanas, que requerem habilidade 
em trabalhar com especialistas humanos e com co-
nhecimentos tácitos que, de forma sucinta, é aquele 
não expresso� Para um industrial, por exemplo, o 
processo de criação de seu produto pode lhe ser tão 
óbvio que, instintivamente, ele pode não sentir ne-
cessidade de detalhá-lo ao Engenheiro de Software�
O documento Guide to the software engineering body 
of knowledge (IEEE, 2004) oferece conteúdo sobre 
as duas primeiras técnicas que viabilizam o trabalho 
de levantamento de requisitos�
Entrevista: antes da sua aplicação, a entrevista deve 
ser planejada. Seus objetivos devem ser fixados, seu 
local e roteiro definidos e os entrevistados criteriosa-
mente escolhidos. Afinal, o entrevistado deve ter o que 
contribuir para o projeto� A interação entre entrevistado 
– que conhece o negócio e entrevistador – que é o 
engenheiro de requisitos, deve buscar revelar concei-
tos, procedimentos e a organização do domínio do 
problema, além de buscar soluções ou projeções de 
soluções que comporão o domínio da solução�
11
As entrevistas mais usuais são as tutoriais, informais 
e estruturadas� Nas entrevistas tutoriais, o entrevista-
do fica no comando, praticamente lecionando sobre 
um determinado assunto� Nas entrevistas informais 
ou não estruturadas, o entrevistador age espontanea-
mente, perguntando ao entrevistado, sem obedecer a 
nenhuma organização� Já as entrevistas estruturadas 
são preparadas pelo entrevistador, que define previa-
mente o andamento do procedimento de aquisição 
de conhecimento�
Aplicação de questionário: se em uma entrevista o 
usuário (ou cliente) é compelido a falar, por meio de 
um questionário ele poderá se expressar de outra 
forma que não a oral� Um questionário geralmen-
te é aplicado por meio de formulário (que pode ser 
eletrônico) distribuído para os futuros usuários do 
sistema� O Engenheiro de Software deve utilizar ques-
tões objetivas e diretas, e que consigam extrair do 
participante respostas sobre o procedimento atual 
adotado� Dessa forma, o questionário é um bom meio 
de identificar como os usuários executam determina-
do procedimento que se tornará uma funcionalidade 
do sistema�
Análise de documentos: essa atividade consiste em 
levantar requisitos por meio da análise da documen-
tação que trata da solução atual, com o objetivo de 
identificar informação de relevância para o desen-
volvimento de solução futura (VAZQUEZ; SIMÕES, 
2016). O objetivo dessa técnica, portanto, não difere 
totalmente do objetivo da aplicação de um questio-
nário, exceto pelo objeto da análise� Ainda segundo 
12
Vazquez e Simões (2016), o termo “documentação” 
deve ser entendido em sentido amplo e incluir pla-
nos de negócios, fluxos de processos atuais, mo-
delos de dados, repositórios de regras de negócios, 
relatórios, manuais, normas, eventuais casos de uso 
existentes e tudo o que for útil para que o Engenheiro 
de Software seja capaz de delinear o domínio do 
problema� 
A realização dessa atividade de análise de documen-
tos inclui basicamente três fases:
 ● Preparação: nessa fase deve-se identificar quais 
as necessidades de informação do Engenheiro de 
Software ou da equipe de requisitos� Tais necessida-
des podem incluir, por exemplo, o entendimento das 
regras do negócio, as informações mais relevantes 
que devem ser apresentadas pelo futuro sistema e 
quais dados devem ser armazenados. Identificadas 
essas necessidades, os documentos mais apropria-
dos para atendê-las devem ser buscados�
 ● Execução: aqui a equipe de requisitos deve estu-
dar a documentação selecionada para extrair dela 
as contribuições para o entendimento do problema� 
Eventuais ausências de respostas podem ocorrer 
nessa fase e, por isso, novas oportunidades deverão 
ser criadas para novas buscas e análises�
 ● Finalização: as buscas e análises feitas devem ser 
consolidadas em um relatório a ser submetido aos 
interessados com aptidão para validar o resultado 
dessa fase� Para facilitar a tarefa, as referências aos 
documentos analisados devem constar desse rela-
tório, incluindo a localização de cada um deles em 
13
meio digital� A tabela 1 ilustra exemplo de um possí-
vel sumário do resultado da análise de documentos�
Tipo Localização
Termo de referência (svn)/projetos/2021/ProjetoA
Nome
Edital do pregão eletrônico
Memória do levantamento
ML01 – Resumo da análise do edital
Tabela 1: Resumo da análise de documentos� Fonte: 
Vazques e Simões (2016, p. 155)
As maneiras que a equipe de requisitos tem à dispo-
sição não se restringem a essas que abordamos� A 
critério do entendimento do cliente com o Engenheiro 
de Software, poderão ser realizadas reuniões estru-
turadas e sessões em que um membro da equipe de 
requisitos apenas observa e faz anotações sobre a 
forma com que um futuro usuário-chave do sistema 
desempenha suas funções, segundo o procedimento 
atual� De qualquer forma, a proximidade saudável 
da equipe com o cliente será um dos fatores que 
determinará o sucesso dessa empreitada�
Apesar do desenvolvimento contínuo aplicado a es-
sas técnicas e sua comprovada efetividade, não se 
pode esperar que os atores do processocoloquem 
todas as informações dos requisitos à disposição da 
equipe de forma voluntária e na primeira vez em que 
forem chamados a fazê-lo� Devemos lembrar também 
14
que sempre existirão conhecimentos que não serão 
compartilhados com a equipe por parecerem óbvios 
ao seu detentor, o que torna ainda mais crítica a ha-
bilidade e experiência dos membros dessa equipe� 
Continuamos nosso percurso agora com o estudo 
da etapa de análise de requisitos�
Análise de Requisitos
Considerando o fluxo estabelecido pela Engenharia 
de Requisitos, ao ser concluída a fase de levanta-
mento (ou elicitação), terá início a fase de análise 
desses requisitos� Espera-se que aqui eles sejam 
analisados e classificados e, como resultado, que 
a equipe tenha em mãos principalmente requisitos 
funcionais e não funcionais� Em poucas palavras, os 
primeiros descrevem as funções que o software irá 
executar e os requisitos não funcionais são aqueles 
que restringem a solução de um problema�
Vazquez e Simões (2016) definem de maneira interes-
sante essa etapa da Engenharia de Requisitos e sua 
relação com a anterior: se a elicitação de requisitos 
serve para descobrir as peças do quebra-cabeças que 
compõem a solução do problema, a fase de análise 
dos requisitos procura montá-lo. A finalidade da exis-
tência dessa fase é a de aumentar o entendimento 
do problema, por meio da aplicação de incrementos, 
organização e melhorias à informação já existente� A 
figura 2 ilustra a análise de requisitos sob esta ótica. 
15
Elicitação e 
gerência de 
requisitos
Análise de
requisitos
Resultado da 
elicitação e da 
gerência de 
requisitos
Aumentar o 
entendimento 
atual do 
problema
Especificações
não
documentais
Requisitos 
funcionais e 
não funcionais
Resultados da análise
Figura 2: Uma visão simplificada da análise de requisitos. 
Fonte: Adaptado de Vazques e Simões (2016)
Observe que a fase de análise de requisitos vem depois 
da elicitação, na ordem em que desenvolvemos seus 
respectivos conteúdos� No entanto, deve-se registrar 
que os dados gerados pela elicitação em um deter-
minado projeto podem ser ambíguos e passíveis de 
revisão, o que forçaria a equipe a retroceder um passo 
e realizar nossas atividades de elicitação� De qualquer 
maneira, a figura mostra que o resultado da elicitação 
será subsídio para a análise de requisitos que, uma vez 
concluída, deverá gerar um quebra-cabeças montado�
Ao fazermos a abordagem específica do processa-
mento da análise de requisitos, teremos que uma das 
primeiras classificações a serem feitas refere-se a 
requisitos de produto e de processo� Requisitos de 
produto referem-se às características próprias do 
16
software a ser desenvolvido� Por exemplo, a equipe 
pode ter levantado que “o software dever verificar se 
um candidato atende a todos os pré-requisitos antes 
que seja autorizado a participar do pleito eleitoral”� 
Esse requisito deverá ser classificado, portanto, como 
próprio do produto�
Já um requisito de processo equivale a uma restrição 
incidente no procedimento de desenvolvimento ou 
na tecnologia aplicada ao software� Como exemplos, 
podemos tomar os seguintes casos: “o software deve 
ser escrito em Java” ou “uma metodologia ágil deve 
ser adotada como modelo de desenvolvimento”� É 
de se imaginar que algumas distinções podem não 
ser tão imediatas, o que pode gerar incertezas no 
projeto. Confira no box Fique Atento logo adiante 
um exemplo relacionado a esse tema�
Outra análise com grande potencial de utilidade é 
aquela relacionada à prioridade de um requisito� A 
equipe pode determinar, por exemplo, que um re-
quisito pode ser classificado obrigatório, altamente 
desejável, desejável ou opcional� Embora tenhamos 
atribuído à equipe essa classificação, o cliente deverá 
apontar as funcionalidades (aqui entendidas como os 
requisitos em questão) que mais valor agregarão ao 
seu negócio e que, portanto, merecerão mais atenção 
e agilidade no desenvolvimento�
Embora todas essas classificações sejam impor-
tantes, a mais imediata é, de fato, a separação dos 
requisitos em funcionais e não funcionais� Os requisi-
tos funcionais descrevem as funções que o software 
17
irá executar. Em outras palavras, eles definem as 
funcionalidades que o software deve disponibilizar 
com o objetivo de capacitar os usuários a realizar 
suas tarefas, e podem ser expressos como serviços 
ou funções que o sistema irá executar�
Um levantamento correto e a descrição clara desses 
requisitos funcionais serão de fundamental importân-
cia para o sucesso do projeto� Em contrapartida, uma 
especificação falha das funções do sistema pode 
gerar ambiguidade e levar a uma situação em que o 
desenvolvedor faça uma interpretação incorreta da 
funcionalidade e em desacordo com o que de fato 
se desejava expressar� Além da clareza na descrição, 
um requisito funcional requer o estabelecimento de 
prazos e alocação de recursos para sua efetivação 
como funcionalidade do sistema�
FIQUE ATENTO
As informações levantadas ao longo da elicitação 
de requisitos podem apresentar-se no formato de 
fragmentos, como este: “Apenas os alunos que 
tiverem ao menos 75% de presença estarão aptos 
ao recebimento do certificado de conclusão do 
curso”� Aparentemente, esse fragmento remete 
ao requisito funcional da emissão do certificado, 
mas não se pode afirmar com segurança que o 
fragmento esteja associado apenas a esse requi-
sito� A depender do caso, o sistema poderá contar 
com uma funcionalidade de emissão de certificado 
voltada ao aluno concluinte e outra funcionalidade 
18
– ligeiramente diferente – que prevê a possibilida-
de de a equipe administrativa emitir um certificado, 
em qualquer tempo (VAZQUEZ; SIMÕES, 2016).
Requisitos não funcionais são aqueles que restringem 
a solução de um problema� Não se referem às fun-
ções específicas do sistema, mas sim a propriedades 
específicas, incluindo tempo de resposta do sistema, 
requisitos de armazenamento, restrições de entrada 
e saída, memória, entre outras� É comum que requi-
sitos não funcionais se refiram de modo universal ao 
sistema, e não a suas peculiaridades� Dessa forma, 
tornam-se, com alguma frequência, mais importantes 
que requisitos funcionais analisados individualmente� 
Considerando essa realidade, podemos tomar como 
exemplo um sistema de aviação que não responde 
aos requisitos de segurança convencionados� Dessa 
forma, o sistema todo estará comprometido e deverá 
ser revisto em seus aspectos de segurança�
Especificação dos requisitos de software
A próxima etapa do processo de Engenharia de 
Requisitos refere-se à produção de um documento 
contendo os requisitos levantados e analisados, que 
podem ser sistematicamente revistos, avaliados e 
aprovados. A especificação de requisitos é, portan-
to, o artefato que documenta os variados requisitos 
levantados na etapa de elicitação e analisados em 
etapa seguinte e que contém a representação da 
informação disponível naquela circunstância tem-
poral do projeto�
19
De acordo com IEEE (2004), uma boa especificação 
de requisitos de software pode propiciar diversos 
benefícios aos clientes e demais envolvidos no pro-
jeto, a saber:
 ● Estabelece a base para a concordância entre 
clientes e fornecedores, naquilo que o software deve 
produzir�
 ● Reduz o esforço para o desenvolvimento� Uma 
revisão cuidadosa dos requisitos na Especificação 
de Requisitos de Software (ERS) pode trazer à tona 
omissões e falhas em fases iniciais no ciclo de de-
senvolvimento quando esses problemas são mais 
fáceis de corrigir�
 ● Fornece base para estimativa de custos e agen-
das� A descrição do produto a ser desenvolvido é 
uma base realista para a estimativa dos custos do 
projeto e pode ser usada como referência de preço 
do produto�
 ● Fornece uma linha de base para validação e ve-
rificação do produto de software. As organizações 
podem desenvolver seus planos de validação e ve-
rificação de forma muito mais produtiva a partir de 
uma boa ERS� 
Em resumo, a criaçãoe utilização desse documento 
é justificada pela sua capacidade de validar as neces-
sidades das partes interessadas no sistema� Além 
disso, por intermédio da especificação é possível 
definir uma solução para as necessidades dos negó-
cios, formar base de informação para a evolução do 
sistema, realizar adaptações para que o documento 
20
sirva como fonte para criação de manuais de usuário, 
estabelecer acordos contratuais e consolidar docu-
mentos para auditoria, quando aplicável� (PMI, 2017)
Antes de encerrarmos nossa abordagem sobre requi-
sitos, cabe registrar algumas considerações sobre 
a elaboração desse documento� Um documento de 
requisitos precisa conter, minimamente, as funcionali-
dades apontadas pelo cliente e validadas pela equipe� 
A forma de se colocar um requisito, especialmente os 
funcionais, é decisivo para sua correta interpretação 
e o redator não deve assumir que o leitor já conheça 
do que trata seu conteúdo� Além disso, a sentença 
descritiva do requisito deverá conter um verbo que 
indique claramente a ação a ser executada, além do 
responsável por ela� Observe um exemplo na tabela 2�
Identificador: RF001 Requisito: Manter Cadastro do Visitante
O condômino cadastra o visitante registrando Nome e Registro Geral�
Identificador: RF002 Requisito: Liberar Acesso de Visitante
O condômino cadastra a liberação de acesso selecionando um visitante 
já cadastrado e indica o período (data e hora de início e data e hora e fim) 
para realizar a visita�
Identificador: RF003 Requisito: Registrar Entrada de Visitante
O porteiro ou guarda verifica se a documentação apresentada pelo visi-
tante confere com os dados apresentados na liberação de acesso (Nome 
do Visitante e Registro Geral) e registra a data e a hora em que o visitante 
entrou no condomínio�
Tabela 2: Exemplo de descrição de requisitos� Fonte: 
Vazques e Simões (2016)
21
Essa estruturação textual claramente facilita a re-
presentação dos requisitos de forma apropriada a 
um projeto de software, qual seja pela utilização de 
casos de uso, prototipação ou esquemas lógicos, por 
exemplo� Feitas essas considerações, avançamos 
para a próxima etapa de requisitos�
Validação dos Requisitos
Depois de usar as técnicas mais variadas de levanta-
mento dos requisitos, realizar uma análise criteriosa 
desses requisitos e especificá-los de acordo com as 
melhores práticas, é de se imaginar que o trabalho 
esteja finalizado e que o resultado dispense ajustes, 
não é mesmo? A resposta é negativa� Não se pode 
finalizar o processo de Engenharia de Software sem 
que os requisitos estejam devidamente validados e 
que a equipe esteja certa que entendeu e traduziu 
corretamente as funcionalidades e restrições do 
sistema�
Assim, como última etapa da Engenharia de 
Requisitos, a validação é o procedimento que deve 
incidir principalmente sobre o documento de espe-
cificação. A validação serve para assegurar que o 
engenheiro compreendeu os requisitos e se foram 
descritos de forma compreensível, consistente e 
completa� No processo de validação, a participação 
do cliente é fundamental e, junto com a equipe de 
requisitos, ele deve verificar se no documento não há 
falta de clareza, sentido dúbio e desvio dos padrões�
22
Uma boa prática de revisão e validação dos requisitos 
pode ser empreendida pela apuração de algumas ca-
racterísticas desejáveis, em conjunto com o cliente� 
Nesse sentido, Pfleeger (2004) propõe as seguintes 
validações:
1. Os requisitos estão corretos?
Essa validação propõe que equipe e cliente analisem 
os requisitos para que se certifiquem de que não há 
erros em suas definições.
2. Os requisitos são consistentes?
Devem ser buscados e corrigidos eventuais requisitos 
ambíguos ou conflitantes.
3. Os requisitos estão completos?
Para assegurarem que o requisito está completo, 
equipe e cliente devem verificar se todos os pos-
síveis estados do requisito, entradas, resultados e 
restrições estão presentes�
4. Os requisitos são realistas?
Essa verificação visa a identificar se o que o cliente 
pede pode, de fato, ser executado�
5. Cada requisito descreve algo que é necessário para 
o cliente?
Aqui é sugerida a verificação da adequação do pe-
dido às reais necessidades do cliente�
6. Os requisitos podem ser verificados?
23
Equipe e cliente devem assegurar que é possível 
criar testes que comprovem que os requisitos fo-
ram satisfeitos�
7. Os requisitos podem ser rastreados?
Essa validação visa a identificar se cada função do 
sistema pode ser associada a um conjunto específico 
de requisitos�
Essas são, portanto, as fases do processo de 
Engenharia de Requisitos� É sempre necessário lem-
brar que você poderá encontrá-las em uma quantidade 
ligeiramente maior em algumas publicações ou com 
fases consolidadas em outras fontes� Haverá também 
a possibilidade de tratamentos específicos serem 
dados aos requisitos, conforme uma ou outra metodo-
logia de desenvolvimento seja considerada� Abordado 
o conteúdo e feitas as ressalvas, avançamos agora 
para o tratamento da Arquitetura de Software�
Arquitetura de Software
Programas de computador estão entre as constru-
ções mais complexas que os seres humanos são 
capazes de criar� Se considerarmos todas as cone-
xões entre seus módulos, as manutenções efetivadas 
nos dados, as interações com os usuários e suas 
eventuais ligações com outros programas, estaremos 
diante de uma estrutura consideravelmente intrin-
cada e que, como tal, deverá requerer um alicerce 
muito bem constituído� Assim como uma casa, um 
24
sistema de computador também requer um desenho 
bem definido antes de ser construído.
De forma genérica, a esse “desenho bem definido” 
damos o nome de Arquitetura do Software� A despei-
to de haver muitas definições para esse termo, todos 
convergem para elementos como projeto, design, 
arcabouço e estrutura de um produto de software� 
De acordo com Lilienthal (2019), a arquitetura de 
software é a estrutura de um produto de software� 
Isso inclui elementos, as propriedades visíveis desses 
elementos e as relações entre eles�
Essa definição menciona elementos e relacionamen-
tos de forma genérica, sem especificá-los. Esses dois 
objetos podem ser usados para descrever uma ampla 
variedade de itens de uma arquitetura� Um módulo, 
por exemplo, contém classes, pacotes, pastas e pro-
jetos, ou seja, elementos comuns disponibilizados 
pelas linguagens de programação� Arquivos, com-
putadores e protocolos de comunicação também 
podem integrar a lista de elementos da arquitetura 
de software�
A expressão Arquitetura de Software, portanto, refere-
-se à estrutura interna de um sistema e explica como 
um software se organiza e funciona, além do seu 
modo de implementação� Se um sistema sofre alte-
rações, sua arquitetura também muda� Os feedbacks 
recebidos, os erros encontrados e as novas soluções 
implementadas são ações que acarretam alterações 
na arquitetura� Assim sendo, é natural imaginarmos 
que a arquitetura de um software deva ser flexível, 
25
ou seja, que ela permita mudanças necessárias para 
seu aprimoramento e adaptação. (GALLOTTI, 2016)
Na mesma direção, O conjunto de conhecimento 
de Engenharia de Software (Guide to the software 
engineering body of knowledge, conhecido pela sigla 
SWEBOK), importante publicação de nível mundial na 
área, conceitua Arquitetura de Software como uma 
descrição dos subsistemas e componentes de um 
sistema de software e as relações entre eles (IEEE, 
2004). A arquitetura, portanto, tenta definir a estru-
tura interna do software (ou a maneira como ele é 
construído e organizado) e, por causa da variedade 
de composição de estruturas de um software, foi 
possível também definir vários estilos de arquitetura.
Um estilo de arquitetura (ou estilo arquitetural) é um 
conjunto de restrições em uma arquitetura que de-
fine um conjunto ou família de arquiteturas que as 
satisfaz� Um estilo de arquitetura pode, portanto, ser 
visto como um metamodelo que pode fornecer a 
organização de alto níveldo software (sua macroar-
quitetura)� Sistemas de Estrutura Genérica, Sistemas 
Distribuídos e Sistemas Interativos são os três exem-
plos de estilo arquitetural mais comuns�
É por meio do estilo arquitetural que poderemos ca-
racterizar a arquitetura de um software, o que pos-
sibilitará, segundo Silva Filho (2008):
 ● Identificar os principais elementos que oferecem 
funcionalidades definidas, tais como um componen-
te de cadastro de usuários ou um componente de 
autenticação em uma aplicação�
26
 ● Identificar mecanismos de interação de um sis-
tema, ou seja, como é feita a comunicação entre 
objetos�
 ● Identificar as propriedades oferecidas por cada 
estilo arquitetural, com base na organização dos 
componentes e nos meios de interação�
Sommerville (2018) trata as ações relacionadas à 
arquitetura de um sistema como “projeto de arquite-
tura”, e o coloca como o vínculo fundamental entre 
a fase de Projeto e a Engenharia de Requisitos, pois 
serve para identificar os principais componentes es-
truturais do sistema e as relações entre eles� Nesse 
sentido, o autor insere o projeto de arquitetura como 
primeiro estágio do Projeto do software e sustenta 
que ele dará à equipe de desenvolvimento e ao cliente 
a oportunidade de conhecer como o software será 
organizado e de projetar sua estrutura geral�
Bem, parece-nos, então, que a definição de uma ar-
quitetura para o sistema trará benefícios em algum 
momento do ciclo de vida desse produto� As pergun-
tas que se seguem são: “Quais as vantagens em se 
ter uma arquitetura definida?” e “Em qual momento 
a equipe de desenvolvimento poderá se beneficiar 
dela?”. Afinal, passar pela fase do projeto sem investir 
tempo em planejar cuidadosamente a arquitetura 
do sistema parece tornar aquela fase mais rápida e 
proveitosa, não é mesmo?
Uma arquitetura bem definida permite a reutilização 
de componentes do sistema (uma classe, por exem-
27
plo), a substituição segura desses componentes e, de 
modo geral, melhora as condições para a evolução 
do software� Além disso, conhecer o estilo arqui-
tetural permite ao engenheiro antecipar o impacto 
que esse estilo terá sobre atributos de qualidade� 
Além disso, facilita a comunicação do projeto� (SILVA 
FILHO, 2008)
Feitas essas considerações, avançamos agora rumo 
ao estudo de como os ambientes de desenvolvimen-
to de software podem ser protagonistas no suces-
so dessa etapa do processo de software� Sigamos 
adiante!
Ambientes de desenvolvimento 
de software
Um dos mais notáveis avanços experimentados pelos 
profissionais de TI no contexto de desenvolvimento 
de programas pode ser creditado às linguagens de 
programação atuais� Com características que reme-
tem à flexibilidade e à simplificação da construção 
das estruturas algorítmicas, elas oferecem recursos 
e funções que conferem agilidade ao processo de 
codificação de um sistema. Esse avanço, no entanto, 
tem sido viabilizado pelo aprimoramento dos ambien-
tes de desenvolvimento de software, que têm nas 
linguagens de programação um dos seus elementos�
Um ambiente de desenvolvimento de software deve 
fornecer ao desenvolvedor uma variedade de fer-
ramentas e facilidades como forma de apoiar o 
processo de construção de um programa – que in-
28
clui a codificação, testes e integração. Na visão de 
Sommerville (2018), essas ferramentas incluem, de 
forma não exaustiva:
 ● Um compilador integrado e um sistema de edição 
dirigido pela sintaxe que permitam a criação, a edição 
e a compilação do código�
 ● O recurso de depuração do código�
 ● Recursos gráficos de edição do código, como as 
ferramentas feitas para permitir a edição de modelos 
UML�
 ● Ferramentas de teste capazes de executar auto-
maticamente um conjunto de testes no código� A 
JUnit é um exemplo dessa ferramenta�
 ● Recursos que permitam a refatoração do código, a 
documentação do código e a visualização de partes 
específicas do programa.
 ● Ferramentas de gerenciamento da configuração, 
incluindo o controle de versões e a integração de 
sistemas�
Por questões práticas, esse conjunto de recursos 
e ferramentas são disponibilizados em Ambientes 
Integrados de Desenvolvimento (IDE, do inglês 
Integrated Development Environment), geralmente 
construídos para apoiarem o desenvolvimento em 
um conjunto de linguagens de programação e que 
tem no Eclipse seu representante mais conhecido 
e usado atualmente� Ele se baseia em uma arqui-
tetura de plug-ins, de forma que é possível torná-lo 
apropriado para uma variedade de linguagens, sim-
29
plesmente acrescentando o plug-in específico à sua 
configuração.
Implantação de Software
A primeira providência a ser tomada em favor do 
entendimento de Implantação de Software é a sua 
necessária distinção de um termo semelhante, e fre-
quentemente utilizado em seu lugar� Implantar um 
software significa torná-lo disponível para uso, co-
mumente por meio da sua instalação em um servidor 
ou outro computador designado� Já implementar 
um software significa, em poucas palavras, criar seu 
código por meio de uma linguagem de programação�
Assim, a implantação de um sistema é o processo 
de disponibilizá-lo para os seus usuários, transferin-
do dados de sistemas existentes e estabelecendo 
comunicações com outros sistemas no ambiente� 
O processo termina quando o sistema é posto em 
operação e disponibilizado aos usuários para a rea-
lização das suas operações (SOMMERVILLE, 2018)� 
A implantação está inserida em um contexto mais 
abrangente, chamado Engenharia de Sistemas, cujas 
etapas incluem a Engenharia de Requisitos, o Projeto 
de Arquitetura, o Particionamento de Requisitos, 
a Engenharia de Subsistemas, a Integração de 
Sistemas, o Teste de Sistema e, finalmente, a própria 
Implantação do Sistema�
A depender do porte do sistema, a sua implantação 
não será constituída apenas pela atividade de instala-
ção de um programa� Via de regra, sistemas maiores 
30
e mais complexos têm sua operação baseada na 
interação com outros sistemas de software, incluindo 
bancos de dados, middleware e outras aplicações� 
Esse conjunto de componentes configura uma pla-
taforma de software que, em outras palavras, é o 
ambiente no qual o software será executado�
É comum encontrarmos menções à implantação de 
um sistema como a sua passagem para o ambiente 
de produção, e a explicação para esse tipo de refe-
rência é bem simples: durante a construção de um 
sistema (incluídos aqui novamente a codificação, os 
testes e as integrações), normalmente é reservado 
a ele um ambiente de desenvolvimento, que pode 
ser configurado em um servidor físico ou em uma 
máquina virtual com designação específica para esse 
fim. A esse ambiente de desenvolvimento os usuários 
não terão acesso, exceto em ocasião em que sejam 
chamados para validar alguma funcionalidade do 
sistema� Terminada a construção do sistema, ele 
então é transferido para o servidor físico (ou máquina 
virtual) em que poderá ser utilizado em sua plenitude 
pelos usuários�
Embora cada sistema possua suas próprias especi-
ficidades, é possível identificar tarefas sequenciais e 
universais, próprias de um processo de implantação� 
A primeira delas é a liberação, normalmente colocada 
em prática logo que o processo de desenvolvimento 
termina� A execução dessa tarefa visa a preparar 
uma versão executável do sistema e disponibilizá-la 
ao cliente, o que inclui a identificação dos recursos 
necessários para que ele seja disponibilizado em 
31
produção� Depois da liberação, segue-se a instalação, 
atividade em que é feita a efetiva transferência do 
sistema para o ambiente de produção e a configu-
ração do sistema� Na sequência, é feita a ativação, 
cujo objetivo é a inicialização da versão executável 
do software�
32
CONSIDERAÇÕES FINAIS
Encerramos aqui a abordagem do conteúdo designa-
do para este módulo� Como tratarmos de assuntos 
de grande alcance – condição na qual requisitos de 
software se encaixa bem –, é salutar que o estudo 
e a atualização nesses assuntos sejam contínuos,de modo a habilitá-lo a utilizar na prática tudo o que 
foi aqui tratado� Iniciamos estes estudos propondo 
conceitos e expondo características dos requisitos, 
com o objetivo de prepararmos o caminho para o 
tratamento das etapas da Engenharia de Requisitos, 
processo no qual eles são levantados, analisados e 
validados, sempre com o objetivo de se tornarem 
subsídio confiável para a elaboração do projeto do 
software�
Como passo seguinte, tratamos da arquitetura de 
um software, como um meio de explicitar as partes 
que o compõem e seus respectivos relacionamen-
tos� A elaboração de um projeto de arquitetura deve 
proporcionar à equipe a possibilidade de promover 
reúso de partes do software e de promover mais facil-
mente sua evolução� Depois, foram feitas abordagens 
conceituais de ambientes de desenvolvimento de 
software (IDE) e de implementação de software, clas-
sificada como etapa final do processo de Engenharia 
de Sistemas�
33
Referências Bibliográficas 
& Consultadas
COHN, M� Desenvolvimento de software com scrum: 
aplicando métodos ágeis com sucesso. Porto Alegre: 
Bookman, 2011� [Minha Biblioteca]
FERNANDES, J� M�; MACHADO, Ricardo, J� Requisitos 
em projetos de software e de sistemas de informa-
ção. São Paulo: Novatec Editora, 2017.
GALLOTTI, G� M� Arquitetura de software. São Paulo: 
Pearson Education do Brasil, 2016.
IEEE Computer Society� Guide to the software engi-
neering body of knowledge. Piscataway, NJ, USA: The 
Institute of Electrical and Electronic Engineers, 2004�
LILIENTHAL, C� Sustainable software architectu-
re: analyze and reduce technical debt. Heidelberg: 
Workplace Solutions, 2019�
PAULA FILHO, W� P� Engenharia de software: funda-
mentos, métodos e padrões. 3. ed. Rio de Janeiro: 
LTC, 2009� [Minha Biblioteca]
PFLEEGER, S� L� Engenharia de software: teoria e prá-
tica. 2. ed. São Paulo: Prentice Hall, 2004. [Biblioteca 
Virtual]
PMI� Guia PMBOK: um guia de conhecimento em 
gerenciamento de projetos. 6. ed. Pensilvânia: Project 
Management Institute, 2017�
PRESSMAN, R�; MAXIM, B� Engenharia de software: 
uma abordagem profissional. 8. ed. Porto Alegre: 
AMGH, 2016. [Minha Biblioteca]
SBROCCO, J� H� T� C�; MACEDO, P� C� Metodologias 
ágeis: engenharia de software sob medida. São 
Paulo: Érica, 2012. [Minha Biblioteca]
SCHACH, S� R� Engenharia de software: os paradig-
mas clássico e orientados a objetos� 7� ed� Porto 
Alegre: AMGH, 2009.
SILVA FILHO, A� M� Arquitetura de software: desen-
volvimento orientado para arquitetura. Disponível em: 
https://www.devmedia.com.br/arquitetura-de-softwa-
re-desenvolvimento-orientado-para-arquitetura/8033� 
Acesso em: 6 nov. 2020.
SOMMERVILLE, I� Engenharia de software� 10� 
ed. São Paulo: Pearson Education do Brasil, 2018. 
[Biblioteca Virtual]
VAZQUEZ, C� E�; SIMÕES, G� S� Engenharia de requi-
sitos: software orientado ao negócio. Rio de Janeiro: 
Brasport, 2016. [Biblioteca Virtual]
WAZLAWICK, R� S� Engenharia de software: conceitos 
e práticas. Rio de Janeiro: Elsevier, 2013.
	Introdução
	Engenharia de Requisitos
	Requisitos de Software
	Engenharia de Requisitos
	Validação dos Requisitos
	Arquitetura de Software
	Ambientes de desenvolvimento de software
	Implantação de Software
	Considerações finais
	Referências Bibliográficas & Consultadas