5EEAS_EBOOK

Prévia do material em texto

ESTUDOS DE CASO
 EM ANÁLISE
 
E
 DESENVOLVIMENTO
 
DE
 
SISTEMAS
Estamos iniciando um novo curso e antes de abordarmos termos mais 
aprofundados, é interessante que sejamos apresentados a alguns dos principais 
personagens que, de uma forma ou outra, ajudaram a contribuir para o 
desenvolvimento da área de Tecnologia da Informação, seja na origem dos 
termos fundamentais, que isso veremos nos grandes pensadores gregos, ou 
seja de forma prática, que é o caso de alguns dos nomes que iremos abordar 
a seguir, dentre eles citamos a máquina de Babbage. Alguns conceitos mais 
complexos, que é o caso da criptografia ou mesmo da definição arquitetural de 
uma máquina, tudo isso faz parte da teoria que iremos abordar ao longo desse 
curso. Mas antes de nos aprofundarmos, vejamos um pouco da história, que tem 
o seu início na Grécia antiga.
Antes de um pouco de história, você poderá também acompanhar a evolução 
da TI sob outra perspectiva: a da sua aplicação no mundo dos negócios, desde o 
tempo em que a atividade era chamada de Processamento Eletrônico de Dados 
(PED) até a sua denominação atual.
Por fim, vamos discutir as possibilidades de mudanças e de criação de novas 
oportunidades de negócios com base no emprego dos recursos da TI.
Estudos de Caso em Análise e Desenvolvimento 
de Sistemas
Introdução 
Estamos iniciando um novo curso e antes de abordarmos termos mais 
aprofundados, é interessante que sejamos apresentados a alguns dos principais 
personagens que, de uma forma ou outra, ajudaram a contribuir para o 
desenvolvimento da área de Tecnologia da Informação, seja na origem dos 
termos fundamentais, que isso veremos nos grandes pensadores gregos, ou 
seja de forma prática, que é o caso de alguns dos nomes que iremos abordar 
a seguir, dentre eles citamos a máquina de Babbage. Alguns conceitos mais 
complexos, que é o caso da criptografia ou mesmo da definição arquitetural de 
uma máquina, tudo isso faz parte da teoria que iremos abordar ao longo desse 
curso. Mas antes de nos aprofundarmos, vejamos um pouco da história, que tem 
o seu início na Grécia antiga.
Antes de um pouco de história, você poderá também acompanhar a evolução 
da TI sob outra perspectiva: a da sua aplicação no mundo dos negócios, desde o 
tempo em que a atividade era chamada de Processamento Eletrônico de Dados 
(PED) até a sua denominação atual.
Por fim, vamos discutir as possibilidades de mudanças e de criação de novas 
oportunidades de negócios com base no emprego dos recursos da TI.
Estudos de Caso em Análise e Desenvolvimento 
de Sistemas
Introdução 
Pode-se dizer que o hardware e o software, tal como 
se encontram no presente, desenvolveram-se nas últimas 
décadas. Entretanto, no campo das ideias, é possível 
estabelecer conexões bem mais ancestrais. Talvez você precise 
incluir alguém ou algum conceito que esteja fora, e se for o 
caso, vá adiante e faça a pesquisa que for necessária.
Um bom início para a nossa história pode ser Aristóteles, 
filósofo do mundo grego, que viveu entre os anos de 384 e 322 
a.C., já que ele é considerado o pai da lógica formal. Aristóteles 
criou um mecanismo de raciocínio, conhecido como silogismo, 
em que parte-se de uma ideia universal para o particular, ou 
seja, deduz-se de uma proposição geral o particular. 
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas
Contribuições de atores-chave relacionados 
com a TI1
Aristóteles - Fonte: Google imagens (2016)
 
É conhecido o exemplo: Todo mamífero é um animal. 
Todo cavalo é um mamífero. Portanto, todo cavalo é um animal 
(Forbelone, 2005). 
Ainda sobre silogismo, segundo (Forbelone, 2005) ele 
é o estudo da Lógica Proposicional (ou Cálculo Sentencial) 
representa um argumento composto de duas premissas 
e uma conclusão, ou seja, é necessário estabelecer um 
relacionamento entre as afirmações e assim demonstramos 
se a mesma é ou não válida. O que será que isto tem a ver 
com a lógica de programação moderna?
Na sequência, vamos até o mundo germânico dos séculos 
XVII e XVIII, para um encontro com Leibniz (1646-1716), 
Figura 1, considerado “o precursor teórico de computação 
moderna”. Para ele, “todo raciocínio, toda descoberta, 
verbal ou não, é redutível a uma combinação ordenada de 
elementos tais como números, palavras, sons ou cores. A sua 
compreensão do valor da aritmética binária para o cálculo 
automático foi fundamental na história da matemática e, 
por consequência, para a computação. Para ele, a lógica não 
poderia deixar dúvidas, deveria ter precisão para que o caráter 
científico fosse mantido. 
Em seus estudos, Leibniz se valeu do sistema aritmético 
binário, língua que teria os números 0 e 1 como símbolos base 
(IME, 2016). Será que o trabalho de Leibniz lhe lembra de 
algum velho conhecido?
Leibniz - Fonte: (Brent, 2016)
 
Mais à frente, encontramos alguém interessado em 
fazer com que uma máquina pudesse executar um trabalho 
repetitivo e que, portanto, pudesse ser submetida a algum 
tipo de programação. Com o intuito de automatizar as imagens 
dos tecidos, pré-programando a mudança dos novelos das 
agulhas e das lançadeiras, evitando as contínuas trocas, 
Joseph-Marie Jacquard, Figura 2, francês que viveu entre 1752 
e 1834, elaborou um sistema baseado em cartões perfurados, 
considerado um dos precursores da programação moderna de 
computadores. 
Esses cartões perfurados permitiam que se produzissem 
diferentes padrões de tecidos, elaborados de forma antecipada 
(History, 2016). Programação de mudança de novelos? 
Cartões perfurados? A nossa cadeia de pensamento segue com 
mais alguns elos. Só para lembrar: até os anos 80, cartões 
perfurados “modernos” ainda eram utilizados.
Por sua vez, foi o cientista, matemático, filósofo, 
engenheiro mecânico e inventor inglês Charles Babbage 
(1791-1871), Figura 3, quem primeiro esboçou o princípio 
de funcionamento de um computador. Esse equipamento, 
que não foi construído na sua época, ficou conhecido como a 
máquina analítica de Babbage e influenciou toda a sequência 
evolutiva da computação (Saraiva, 2016). Já estava lá 
contemplada a noção básica de processamento de dados: 
entrada, armazenamento, processamento e saída, que tal?
Joseph-Marie - Fonte: (History, 2016)
Charles Babbage - Fonte: (Saraiva, 2016)
 
Ada Lovelace, Figura 4, britânica que viveu entre 1815 
e 1852, entrou para a História como a primeira pessoa a 
programar da História, por ter escrito o primeiro algoritmo 
para ser processado por um dispositivo, a máquina analítica 
de Charles Babbage, de quem foi contemporânea. Ela 
descobriu conceitos importantes que viriam a ser amplamente 
usados depois na programação, tais como loops (laços) e 
procedimentos (sub-rotinas) (Biography, 2016). Mais algumas 
contribuições na nossa longa jornada: os conceitos tão caros 
para a programação, como laços e rotinas.
O americano Herman Hollerith (1860-1929) construiu 
o que se convencionou chamar de o primeiro computador 
mecânico e lançou as bases para o processamento de dados 
moderno. Ele concebeu uma máquina para processar os dados 
do censo americano de 1890 a partir de cartões perfurados, 
os quais foram depois computados sistematicamente. O 
resultado foi que, em pouco mais de um ano, o censo total 
estava concluído e em seis semanas já se sabia o tamanho da 
população. A título de curiosidade: em 1911, uma firma criada 
por Hollerith fundiu-se com outras três companhias para formar 
a Computing Tabulating Recording Corporation, sendo a nova 
empresa mais tarde chamada de IBM (Cruz, 2016). 
Finalmente, estamos falando de uma máquina que pode 
ser classificada como um computador rudimentar e que foi, 
não apenas construída, como posta em uso.
Ada Lovelace - Fonte: (Biography, 2016)
Hermam Hollerith - Fonte: (Cruz, 2016)
 
John von Neumann, que tem como nome de batismo János 
von Neumann. Quando criança era chamado de Jancsi, um 
diminutivo para János, depois, já nos Estados Unidos, passou 
a ser conhecido por Jhonny. Matemático húngaro, (1903-
1957),em Budapeste. Durante a segunda Guerra Mundial, foi 
um dos cientistas a participar no desenvolvimento da bomba 
atómica em Los Alamos. Em 1945, enquanto preparava um 
relatório sobre a capacidade dos computadores, ele escreveu 
“First Draft of a Report on the EDVAC” que sugeria a utilização 
da linguagem binária e que os programas e outros dados 
deveriam estar na memória interna do computador. 
Ele também foi um dos responsáveis pela criação do 
ENIAC (Eletronic Numeric Integrator and Computer), o 
primeiro computador para uso profissional (militar). Nesse 
momento realizava-se uma programação por hardware, ou 
seja os comandos eram executados por meio de ligações de 
cabos e conectores. 
Ainda em 1945 ele publica outro trabalho intitulado 
EDVAC (Eletronic Discrete Variable Automatic Computer), 
onde o principal objetivo é a organização do computador em 
quatro áreas principais: Unidade Central de Controle, Unidade 
Aritmética e Lógica, Memória e um conjunto de Dispositivos 
de Entrada e Saída (Periféricos). Com isso temos a sua 
principal contribuição, que foi a arquitetura de Von Neumann. 
(Biography, 2016)
John von Neumann - Fonte: (Biography, 2016)
 
Alan Turing (1912-1954), Figura 6, foi um cientista da 
computação britânico que criou um teste, que leva seu nome, 
em que um humano entra em contato com uma máquina para 
obter respostas, sendo considerado o princípio fundamental 
da Inteligência Artificial. Na Segunda Guerra Mundial, Turing 
foi incumbido de chefiar uma equipe para decifrar o Enigma, 
um código de comunicação das tropas alemãs. Foi então 
construída a máquina eletromagnética Colossus, considerada 
a precursora do computador digital. 
Mas, para o que mais nos interessa aqui, ele foi influente no 
desenvolvimento da ciência da computação e na formalização 
dos conceitos de algoritmo e de computação, com sua máquina 
de Turing, desempenhando um papel importante na criação 
do computador moderno (Hodges, 2016). Para conhecer um 
pouco sobre a máquina Enigma, sugiro que você assista ao 
vídeo1 “Demonstração Máquina Enigma”, apresentado pelo 
pesquisador Ivan Boesing, da UFGRS.
Num grande salto, passamos para a segunda metade do 
século XX, para encontrar alguém a quem todos nós devemos 
muito. Nascido na Inglaterra em 1955, Sir Tim Barners-Lee 
é reconhecido como o criador da Web (ou World Wide Web, 
como ele a chamou), a rede que opera no ambiente da internet 
e que possibilitou a sua popularização, tal qual conhecemos 
hoje. Com sua criação, Berners-Lee foi um dos principais 
participantes da revolução tecnológica do final do século XX 
e início do XXI, exercendo profunda influência no modo de se 
fazer negócios e, consequentemente, em nossa vida em geral 
(RIGBY, 2012).
Alan Turing - Fonte: (Hodges, 2016)
__________________ 
1 https://www.youtube.com/watch?v=VMJeDLv2suw 
 
Outro grande feito de Berners-Lee – além da criação da Web 
– foi que “tendo inventado algo que se tornaria extremamente 
útil e serviria de base para a grande virada econômica ocorrida 
no setor de informação, ele abriu mão de sua ideia. Berners-
Lee jamais ganhou dinheiro diretamente com sua invenção”É 
verdade que alguns nomes não foram citados, com isso sugiro 
que você possa também realizar a sua pesquisa, seja para 
complementar o que foi informado como também para incluir 
outros personagens, também muito importantes, a essa 
nossa linha do tempo. Uma possível história poderia ser a dos 
laboratórios da Bell Telephone, ou quem foi Ted Hoff? E nos 
tempos atuais, temos nomes importantes? Por exemplo seria 
importante pesquisarmos sobre a grande disputa entre Bill 
Gates e Steve Jobs? Quem foram essas pessoas? Quem foi 
Steve Wozniack? A história do Linux, já teve curiosidade de ir 
atrás, a saga do software livre? Ficam essas motivações para 
sua pesquisa.
Tim Barners-Lee - Fonte: (History, 2016)
 
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas
Mudanças de foco do uso da TI2
Outra abordagem sobre as origens e a evolução da 
Tecnologia da Informação diz respeito às empresas e aos 
negócios. Vamos ver agora algumas transformações que 
a TI passou a partir do final dos anos 50, quando começou 
efetivamente a ser empregada nas organizações. 
Para melhor entendimento, podemos dividir a evolução 
da TI comercial em três fases, conforme o Quadro 1.1, de 
onde destacamos alguns itens para a nossa análise. Veja, 
inicialmente, a mudança na denominação de cada fase, com 
os respectivos períodos.
Quadro 1.1: Evolução do foco no uso da TI
Fonte: Francisco Pinto (2015)
 
As fases exemplificadas no Quadro 1.1 acima, pode ser 
detalhada da seguinte forma:
Deve ser observado aqui que, no início, os usuários 
eram todos pessoas conhecidas, faziam parte da rede de 
relacionamentos do pessoal do PED, o funcionário de TI 
também era, basicamente, um funcionário do departamento, 
já que em geral trabalhavam fisicamente muito próximos. À 
medida que o tempo foi passando, os usuários da TI deixaram 
de ser pessoas conhecidas da área, passando para a condição 
de desconhecidos. 
No início, todos os usuários interagiam com o pessoal 
da TI e eram em pequeno número. Depois, aumentou 
significativamente o número de usuários, departamentos, 
de tal maneira que hoje são contados aos milhares, em 
determinados negócios, aos milhões, como o caso de empresas 
de grande porte que alocam o setor de TI em uma única sede, 
dando suporte para todas as filiais, fazendo assim com que o 
setor de TI seja algo cada vez mais distante do cliente final. 
Além disso, foram incorporados aos grupos de usuários, 
com a passagem de uma fase para outra, os ocupantes de 
cargos de gestão e também pessoas que trabalham em outras 
empresas, como clientes e fornecedores. 
Na 1º fase, os usuários dos tempos de PED eram os funcionários de 
cada departamento da empresa, o que significa dizer que as soluções 
adotadas eram bem específicas, sem considerar as integrações com 
outras áreas. 
Na fase 2, ou era da informática, o usuário passou a ser os funcionários de 
toda a organização, em parte devido à chegada dos microcomputadores 
naquele período, o que diminuiu a dependência da área de TI para 
atender às suas demandas. 
Na 3ª fase, ou era da Tecnologia da Informação, ou simplesmente 
(T.I.), o usuário passou a ser qualquer pessoa – física ou jurídica – que 
tivesse qualquer interesse na organização. 
 
Se fizermos uma analogia entre as fases teríamos algo 
do tipo:
Podemos analisar algumas outras abordagens que 
influenciaram a evolução da TI, como por exemplo no que 
diz respeito à integração. Isto significa trocas de dados, 
informações, documentos e outros, entre os diversos agentes 
envolvidos, sejam departamentos internos ou mesmo órgãos 
do ambiente externo da empresa. Outro nome que podemos 
utilizar para essa prática seria o reuso ou compartilhamento 
de solução. 
Na 1ª fase, como pode ser visto no Quadro 1.1, 
praticamente não havia integração, cada solução (sistema 
de informações) era construída apenas para o respectivo 
departamento, solução individualizada. Isso gerava um custo 
muito alto para a organização pois, imaginemos um caso 
de uma empresa com três departamentos, uma solução era 
necessária ser feita e cerca de 80% da mesma era igual aos três 
departamentos, só havendo os 20% que caracterizava o setor, 
nessa época cada setor aplicava a sua solução ao problema, 
não havia o compartilhamento da informação. No máximo, 
um sistema de informações gerava um arquivo magnético (ou 
gravado em cartões perfurados) a ser lido por outro. 
Na sequência, a integração foi ganhando corpo, até a 
fase atual, seguindo a cadeia de valor, onde processos de 
uma empresa são integrados a processos daquela que está na 
sequência do processo produtivo. Hoje uma solução pode ser 
compartilhada de forma integral em todos os setores por meio 
de algumas técnicas de reuso de software e modularização 
de pacotes. Abaixo temos um exemplo que agrega um pouco 
sobre a cadeia de valor, veja a Figura a seguir:Fase 1 – Se um departamento, por exemplo um setor financeiro da 
empresa, tiver uma demanda, um grupo de analistas e programadores 
iriam ao encontro de um responsável técnico pela demanda e os mesmos 
ficariam trabalhando junto durante um tempo indeterminado.
Fase 3 – O usuário solicitante da demanda, pode ser qualquer funcionário 
da organização, seja ele da mesma sede em que a TI está localizada, ou 
seja de outro estado ou país. Com isso, para que a demanda seja feita 
de forma remota, foi necessário o aprimoramento de metodologias de 
trabalho, para que o atendimento das demandas sejam atendidas com 
o mínimo de ocorrência de erro.
 
Por meio da análise da Figura acima, o autor conclui 
que a cadeia de suprimento tem o seu foco na sequência de 
transformações por que passa um produto físico. Assim, a 
Empresa “A” produz um componente da matéria-prima (ferro, 
por exemplo), que é transformado em aço pela Empresa “B”, 
que se torna um insumo para a Empresa “C”, que é responsável 
pela produção de um fogão, por exemplo. 
Ainda analisando a Figura 9, o autor informa que a cadeia 
de valor, por sua vez, é orientada pela geração de valor a 
cada etapa da produção. Como exemplo, a Empresa “A” é uma 
fazenda, que produz leite. Ao transformar o leite em queijos 
e iogurtes e transportá-lo até “C”, a Empresa “B” agrega valor 
ao produto, o que se reflete no preço cobrado. A Empresa 
“C”, por sua vez, ao disponibilizar os queijos e iogurtes em 
pontos comerciais de fácil acesso para o cliente, agrega mais 
valor ainda aos produtos. A cadeia de valor está na base da 
aplicação de soluções de TI que visam a integrar processos 
internos de empresas que se conectam ao longo da sequência 
de produção. Neste exemplo, poderia haver um sistema de 
informação de controle do estoque das lojas de “C” integrado, 
automaticamente, ao sistema de produção da Empresa “B”, 
onde novos pedidos de queijos e iogurtes seriam disparados 
sempre que o estoque atingisse um limite pré-definido. 
Cadeias de suprimento e de valor - Fonte: Nellis e Parker (2003)
 
É claro que hoje já existem meios de integrar os 
sistemas, mesmo que as empresas utilizem soluções de 
diferentes fornecedores. Pense nisto e verifique se a empresa 
em que você trabalha faz parte de uma corrente como está 
e, adicionalmente, qual pode ser a contribuição da TI para 
melhorar o fluxo da produção.
Por nível organizacional entende-se a posição em que 
determinado cargo encontra-se na estrutura organizacional 
de uma empresa. Em geral, são três os níveis: estratégico, 
tático e operacional. Como pode ser visto no Quadro 1.2, o 
nível estratégico compreende a alta administração, onde se 
encontram o Conselho de Administração e o presidente, com 
seu staff2. Neste nível, o foco está concentrado no ambiente de 
negócios em que a empresa está inserida e nas possibilidades 
de médio e longo prazo. 
Segundo (Efraim, 2010) o meio ambiente em que 
as organizações estão operando tem se tornado cada vez 
mais complexo. Essa complexidade, de um lado cria novas 
oportunidades, mas do outro cria vários problemas. Como o 
caso citado pelo autor da competição que pode haver entre os 
vários setores concorrentes do mercado. O autor ainda define 
algumas das principais responsabilidades da organização, 
que seriam:
Quadro 1.2: Decisões por nível organizacional
Fonte: SENAC-RJ (2009)
__________________ 
1 Staff se refere a um grupo de pessoas alocadas a um determinado grupo de trabalho
 
(Efraim, 2010) afirma que um dos maiores objetivos do 
suporte computacional de decisões é a facilidade de aproximar 
o desempenho e performance atual da performance desejada, 
bem como definir uma estratégia para atingir isso.
Tudo isso está bem relacionado com o termo Business 
Inteligence (BI), que tem como definição, segundo (Efraim, 
2010) um termo guarda-chuva que combina arquitetura, banco 
de dados, ferramenta analítica, aplicações e metodologias. 
Uma das maiores complicações que gira em torno desse 
termo é a sopa de letras que tem associada ao BI, tais como 
Executive Information System (EIS), Business Performance 
Management BPM, entre outros. 
Ainda segundo (Efraim, 2010) o principal objetivo do BI 
é permitir que hajam acessos interativos (as vezes em tempo 
real) aos dados, permitir a manipulação dos dados e dar 
todo o suporte ao gestor para que o mesmo possa fazer uma 
análise crítica do dado sempre que necessário. Através de uma 
análise histórica ou atual dos dados o gestor terá a capacidade 
de tomar uma decisão com o máximo de informação possível. 
Por fim, podemos dizer que o processo do BI consiste em 
transformar a informação em uma decisão e posteriormente 
em uma ação.
Estratégia
Parceria e colaboração
Respostas em tempo real
Agilidade
Aumento de produtividade
Dentre outros
 
Convido você a fazer uma reflexão e verificar que, nos 
primórdios da TI, as soluções eram desenvolvidas apenas para 
atender às necessidades do nível operacional dos negócios, 
com soluções tais como a folha de pagamentos, o controle 
do estoque (materiais) ou os registros da contabilidade, sem 
pensar na evolução dos sistemas ou manutenções. No processo 
evolutivo, passaram a ser disponibilizadas informações também 
para os ocupantes de cargos da média gerência (nível tático) 
e, por fim, o alto escalão ou alta gerência (nível estratégico). 
Assim, se no início o foco estava no processamento de 
grandes quantidades de dados e a geração de relatórios para 
dar suporte às operações diárias em uma linha de produção, 
atualmente devemos focar o atendimento dos gestores ou 
conselheiros, com soluções baseadas em modelos como 
Business Intelligence (BI), Balanced Scorecard (BSC) , entre 
outros, com o objetivo de tomada de decisões estratégicas, a 
fim de otimizar o desempenho do setor, de uma forma geral. 
Atividades primárias e de apoio - Fonte: Porter (1989)
 
Podemos verificar por meio da imagem do autor um outro 
aspecto relevante que é a abrangência do uso da TI. Temos 
que na 1ª fase, os recursos eram empregados basicamente 
em atividades de apoio, de forma bem individual, tais como 
recursos humanos e contabilidade, sem contemplar as 
atividades primárias (fins) das empresas. Uma das razões para 
esta escolha é que os processos organizacionais associados às 
atividades de apoio são, em geral, bem estruturados. Isto quer 
dizer que os componentes dos processos, como as entradas, 
os procedimentos e as decisões, além das saídas geradas são 
basicamente constantes e conhecidos, o que facilita a definição 
de um algoritmo no padrão solicitado, deixando assim o 
software adaptado para a realidade do setor solicitante.
 Na segunda fase, as atividades primárias (fins das 
empresas) passaram também a serem servidas pela TI e, 
atualmente, entende-se que é fundamental o alinhamento dos 
recursos da TI com as necessidades do negócio, para que assim 
possa ter um maior retorno e confiabilidade. O alinhamento 
com os negócios significa que as soluções de TI devem dar 
suporte ou viabilizar alguma definição da empresa, quanto ao 
alcance de um objetivo, como por exemplo a ocupação de 
25% do segmento de clientes, a execução de uma estratégia, 
como por exemplo a incorporação de uma empresa adquirida, 
ou a composição de produtos e serviços, dentre outros. 
Poter (1989) na Figura 10 no apresenta um dos modelos 
mais conhecidos sobre a classificação das atividades internas de 
uma empresa, esse modelo é um clássico. Ainda de acordo com 
Porter (1989), as atividades primárias são aquelas diretamente 
ligadas à produção, ao marketing e à comercialização. O serviço 
de atendimento pós-venda também se enquadra nesta categoria. 
No caso de uma fábrica de software, o desenvolvimento e a 
manutenção dos produtos comercializados são atividades 
primárias, ou seja o principal foco da organização, bem como os 
canais de comunicação e comercialização e os relacionamentos 
estabelecidos com os clientes. 
 
As atividades de apoio, por outro lado, complementam 
e dãosuporte para as atividades primárias da organização. 
Continuando a análise de uma suposta fábrica de software 
podemos encontrar algumas atividades de apoio na gestão 
dos recursos humanos, nas finanças e na contabilidade da 
organização. Um caso que ilustra apropriadamente essa 
questão é o segmento dos bancos. 
Com isso conclui-se que a orientação passou por um 
intenso processo de mudança de foco. Se no início, fase 1, as 
atenções estavam voltadas para a automação dos processos 
da empresa, na fase 2 já havia preocupação com a redução de 
custos e com a geração de vantagem competitiva em relação 
aos concorrentes, a partir do uso dos recursos da informática. 
Na fase 3 o foco já ficou na geração de valor, através de 
melhorias no desempenho organizacional, do suporte às 
atividades e demandas do negócio e do retorno sobre os 
investimentos (ROI2). 
Não foi excluída a necessidade de soluções que automatizem 
atividades rotineiras, com sua sequência de passos que podem 
ser expressos sob a forma de um algoritmo. Desta forma, os 
esforços das empresas podem ser orientados para atividades 
que são tipicamente não-estruturadas e dependem da atuação 
do pessoal. A redução de custos continua algo a ser buscado 
pelas empresas, para evitar o desperdício de recursos e gerar 
vantagem competitiva, pois cada vez mais os clientes buscam 
empresas que possam lhe fornecer algo novo e barato, então 
o que puder ser reduzido de custo irá fazer com que a sua 
organização fique a frente dos seus concorrentes. 
__________________ 
2 Da expressão em inglês Return on Investment (tradução do autor).
 
Hoje, cada investimento feito em TI, seja na aquisição de 
um novo sistema de informações, seja na construção de um 
data center, ou qualquer outro, deve dar o devido e esperado 
retorno, qualquer que seja o critério de medição. Por exemplo: 
a diretoria de uma empresa pode autorizar a execução de um 
projeto para substituir a atual infraestrutura de redes, mas vai 
querer saber em quais dimensões – satisfação dos usuários, 
ganhos de produtividade, maior disponibilidade ou velocidade, 
etc. – serão obtidos retorno para o investimento do capital. 
Uma vez esse retorno apresentado, uma comissão irá julgar 
se o prazo para o retorno é favorável ao investimento feito, 
caso seja aceito o mesmo é aprovado e implantado.
Naturalmente, tudo isto traz consequências para os 
profissionais que atuam na área de TI. Seja você um analista 
de requisitos, um programador, um analista de banco de dados 
ou de suporte, um web designer, trabalho com a qualidade 
de software, enfim, não importa a sua área. Você deve estar 
atento para o fato de que: 
seus usuários podem estar em qualquer parte.
todos os ocupantes da gestão e da operação do negócio 
têm necessidades que devem ser atendidas.
a solução com a qual você está trabalhando pode 
ser parte de algo maior, incluindo partes de outras 
empresas.
acima de tudo, o resultado do seu trabalho deve 
contribuir para gerar valor para o negócio.
 
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas
Transformações de negócios com a TI3
Nesta Parte III, vamos abordar aspectos dos ambientes 
interno e externo de uma empresa, para que você possa melhor 
compreender como a TI pode – e deve – ser empregada para 
transformar os negócios, de maneira que a empresa possa se 
manter competitiva ao longo do tempo e ser capaz de gerar 
valor para todos os seus stakeholders1. 
A partir da Figura abaixo, podemos fazer uma análise 
do ambiente interno de uma organização observar as 
características das demandas de cada um dos três níveis 
organizacionais e o que pode ser feito para atendê-las. 
Como podemos ver na Figura abaixo, há uma variação 
na forma de trabalhar na empresa se comparado os níveis 
operacional e estratégico. No primeiro nível, o operacional, os 
supervisores e técnicos lidam em geral com grandes volumes 
de dados, a linha de produção propriamente dita, enquanto 
que a média gerência e o alto escalão ou alta direção, precisam 
de informações mais elaboradas para que possam ser mais 
precisos na tomada de decisões.
Utilização da TI pelos níveis organizacionais - Fonte: Stair e Reynolds (2011)
__________________ 
1 O termo original em inglês – stakeholder – é utilizado livremente no Brasil como equivalente a partes 
interessadas, ou seja, pessoas ou organizações que têm algum interesse em uma empresa ou em um projeto.
 
As atividades do dia-a-dia são mais encontradas nos níveis 
mais baixos, pois se caracterizam por atividades rotineiras, 
enquanto que o suporte à tomada de decisões, proporcionado 
pela TI, é mais demandado pelos níveis mais altos, onde as 
decisões são menos estruturadas. Nos mais altos níveis podem 
ser utilizados, por exemplo, soluções da categoria de Sistemas 
de Apoio às Decisões (SAD), ferramentas capazes de produzir 
cenários futuros de ambientes de negócios com simulações, 
modelagem analítica, entre outras aplicações. O volume de 
entradas e saídas, em termos de dados e de informações, é 
mais elevado no nível operacional. 
Por fim, o tipo de informações demandadas pelos gestores 
de alto nível faz com que o processamento e a análise das 
saídas se tornem mais sofisticados e complexos, ente outras 
razões porque muitos dos dados e informações devem ser 
coletados tanto no ambiente interno da empresa, quanto 
no externo, e os processos apresentam baixa estruturação 
(STAIR; REYNOLDS, 2011).
Com isso podemos ver uma forma em que a TI pode 
auxiliar as organizações em uma renovação, como um exemplo 
temos as soluções desenvolvidas, onde podemos destacar 
dentre elas: Sistemas de informações, banco de dados, dentre 
outros. Tudo isso deverá ser desenvolvido considerando as 
características passadas aos gestores da área de TI.
Ainda no que diz respeito ao ambiente interno de uma 
organização, podemos verificar um outro modelo o Balanced 
Scorecard (BSC)2, que está representado na Figura a seguir, 
que identifica quatro perspectivas de análise para uma 
empresa: financeira, clientes, processos internos e aprendizado 
e crescimento (KAPLAN; NORTON, 2000).
__________________ 
2 BSC, Balanced Scorecard, modelo de análise de gestão e de estratégia, proposto por Kaplan e Norton e 
atualmente utilizado largamente pelo mercado. Vide a obra destes autores nas referências.26 Op. cit.
 
O autor informa que se analisarmos a visão Financeira, 
cujo lema adotado pode ser visto na Figura acima, as 
transformações que podem ser aplicadas a uma empresa se 
referem a incremento da lucratividade, ao ROI ou obtenção 
de retorno sobre os investimentos realizados, incremento da 
receita por unidade de produção, aumento do valor da empresa 
para os acionistas, entre outros. Desta forma, a empresa 
poderá se apresentar para os investidores como inovadora, 
capaz de gerar valor para os stakeholders e, portanto, atraente 
para o aporte de seu capital.
Com relação à perspectiva do cliente, a TI pode ser 
empregada para aumentar a participação da empresa nos 
mercados em que atua, para elevar a satisfação do cliente, 
para conseguir a retenção de clientes que já transacionam 
com a empresa, para conseguir um crescimento da base de 
clientes e assim por diante.
Na perspectiva dos processos internos, é possível 
alcançar um incremento da capacidade de produção, favorecer 
o alcance de resultados projetados, otimizar o consumo dos 
recursos empregados, entre outros ganhos.
As perspectivas do BSC - Fonte: Kaplan e Norton (2000)
 
E, na perspectiva do aprendizado e crescimento, estamos 
tratando de formas diversas de capital: humano, informação, 
organizacional, entre outros. Para o capital humano, a TI 
pode ser empregada para desenvolver habilidades, talentos, 
entre outros. O capital da informação pode ser favorecido 
pela TI, através da montagem de bancos de dados, sistemas 
de informação, etc. E o capital organizacional pode ter a TI 
como aliada para promover transformações em áreas como a 
cultura, a liderança, entre outros.
Agora é com você:depois de tudo o que estudamos 
até aqui, comece pensando se há algum personagem que 
pode ser somado à nossa lista de construtores da TI. Sua 
contribuição será muita bem-vinda. Procure também expandir 
seu conhecimento, estudando os temas abordados nas obras 
que fazem parte das referências e outras mais. Assim, você 
estará desenvolvendo suas competências para gerar valor para 
as empresas e para a sociedade em geral com o seu trabalho!
Referências
 
Ada Lovelace Biography. Disponível em: <http://www.biography.
com/people/ada-lovelace-20825323>. Acesso em: 18 fev. 2016.
Cruz, F. Herman Hollerith. Disponível em: <http://www.columbia.
edu/cu/computinghistory/hollerith.html>. Acesso em: 18 fev. 
2016.
Efraim, T. Business Intelligence - a managerial approach. Boston: 
Prentice Hall, 2010.
Forbelone, A. L. Lógica de programação: a construção de 
algoritmo e estruturas de dados. São Paulo: Pearson Prentice Hall.
Gotfried Wilhelm von Leibniz. Disponível em: <http://www.
brentmblackwell.com/obsessions/men/Leibniz.html>. Acesso em: 
18 fev. 2016.
Hodges, A. (3 de 4 de 2016). The Enigma. Disponível em: <http://
www.turing.org.uk/>. Acesso em: 20 abr. 2016.
Joseph Marie Jacquard. Disponível em: <http://www.
computinghistory.org.uk/det/19901/Joseph-Marie-Jacquard/>. 
Acesso em: 20 abr. 2016.
IME. (01 de abril de 2016). História da matemática. Disponível 
em: <http://www.ime.unicamp.br/~calculo/history/leibniz/leibniz.
html>. Acesso em: 20 abr. 2016. 
ISAACSON, Walter. Os inovadores. São Paulo: Companhia das 
Letras, 2014.
KAPLAN, Robert; NORTON, David. Organização orientada para 
a estratégia: como as empresas que adotam o balanced scorecard 
prosperam no novo ambiente de negócios. Rio de Janeiro: Campus, 
2000.
NELLIS, Joseph; PARKER, David. Princípios de economia para 
os negócios. São Paulo: Futura, 2003.
PORTER, Michael. Vantagem competitiva: criando e sustentando 
um desempenho superior. 25. ed. Rio de Janeiro: Elsevier, 1989.
RIGBY, Rhymer. 28 Mentes que mudaram o mundo: os maiores 
desbravadores da gestão em todos os tempos. Rio de Janeiro: 
Elsevier, 2012. 
SENAC-RJ. Curso de Especialização em Governança de TI: 
material didático. Rio de Janeiro, 2009.
STAIR, Ralph M.; REYNOLDS, George W. Princípios de Sistemas 
de Informação. 9. ed. São Paulo: Cengage, 2011.
Referências
 
Estudo de 
Caso 01:
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas
Evolução da TI1 
O objetivo deste estudo de caso é trabalhar a proposição de 
soluções de TI alinhadas com as demandas do mercado, para 
entender como os modelos de negócios podem ser transformados 
com base na utilização dos recursos tecnológicos, conforme foi 
estudado na aula teórica 1. 
Neste caso, o aluno terá a oportunidade de discutir como uma 
alteração conceitual posta em prática mudou o negócio de 
uma montadora de caminhões. Poderá, finalmente, entender o 
funcionamento de um complexo industrial que é estruturado como 
uma rede de cooperação. Essa análise faz a comparação entre o 
modelo implantado com o nome de Fordismo e um outro termo, 
o Toyotismo.
1. Introdução1
As empresas, de uma forma tradicional, utilizam como modelo de processo de 
montagem o implantado pela Ford por volta do ínico do século XX. Tal modelo era 
conhecido como fordismo. Um dos principais fatores dessa abordagem era a forma em que 
a montadora trabalhava, a mesma sempre contratava mão de de fornecedores, externos 
os produtos que necessitava na linha de produção. Nesse caso, a única relação que 
havia entre as partes, era meramente comercial, onde a fábrica só comprava o produto, 
que poderia ser peça de qualquer tipo, e a fábrica ficava responsável pelo processo 
de montagem e controle de qualidade. Controle esse que era feito após o termino da 
produção do carro.
__________________ 
1 Estudo de caso adaptado de Como a Volkswagen administra sua cadeia de suprimentos no Brasil, disponível em TURBAN et al. (2010, pp. 394-395).
 
 
Com a crise mundial, por meio da Segunda Guerra Mundial, essa forma de 
produção, passou a ser substituída, por uma outra que era aplicada nas fábricas das 
montadoras japonesas da Toyota, o processo era chamado de toyotismo.
Nesse processo, a montadora e os principais fornecedores atuam de forma 
integrada, em um mesmo local físico, no parque industrial, em um arranjo categorizado 
como rede de cooperação, operando com base no conceito de cadeia de valor. 
Com o toyotismo a montadora gerencia, controla e monitora a produção, com 
cada fornecedor inserindo seus componentes e peças, enquanto o veículo avança pela 
linha de montagem. O ponto fundamental de distinção entre os modelos é que nesse 
processo, todos os agentes envolvidos no processo de montagem, seja os fornecedores 
de peças ou qualquer outro fornecedor, compartilham todos os riscos, ganhos e perdas. 
Problemas existentes em um processo qualquer da fase de produção são vistos como 
um todo pela rede e a solução deve ser construída conjuntamente.
 
Como muitas outras montadoras, a Volkswagen Brasil (VWB) sempre trabalha com 
muitos fornecedores nas suas linhas de montagem. Alguns problemas eram notados 
no processo, como por exemplo, os componentes e as peças eram despachadas para 
as fábricas da VWB, onde funcionários montavam os caminhões da empresa. Mas a 
cadeia de suprimentos era longa demais e frequentemente havia problemas de toda 
ordem. Sempre que ocorria um erro, a VWB precisava esperar que um parceiro viesse 
à montadora para resolver a questão. Além disso, os materiais chegavam com atraso e, 
assim, a montadora mantinha elevados níveis de estoques de segurança, para enfrentar 
os atrasos. Além disso, a qualidade dos componentes e peças entregues também era 
comprometida. 
2. Panorama e cenários
 
Um outro problema era a falta de comprometimento dos fornecedores com os 
produtos finais da VWB, que viam a montadora apenas como um cliente. Com isso, a 
negociação com os fornecedores era bem onerosa e era necessário muito tempo para 
a solução dos problemas, isso fazia com que os custos da fabricação fossem cada vez 
mais elevados.
No que diz respeito a montagem de caminhões, a VWB optou por uma mudança 
total em sua cadeia de suprimento. Tal fato ocorreu na construção da nova fábrica que 
fica no estado do Rio de Janeiro. Como exemplo dessa fábrica, nela há apenas 1.000 
funcionários, isso a torna uma fábrica relativamente pequena. Desses funcionários, 
apenas 200 deles são de fato funcionários da casa, que tem como responsabilidade o 
processo de qualidade, os demais 800 funcionários participam da linha de produção, no 
processo de montagem e são funcionários de empresas parceiras.
O maior objetivo que a empresa queria alcançar quando propôs uma linha de 
produção mais enxuta, foi o corte de gastos por meio da redução do número de peças 
outros itens com defeitos, com isso também foi possível o corte de custos relativos a 
mão de obra e assim foi possível investir na qualidade do processo.
 Os principais fornecedores da VWB, depois de terem sido submetidos a um complexo 
processo de recrutamento e seleção, têm seu próprio espaço físico na fábrica, mas 
entregam e gerenciam seus componentes, suprimentos e trabalhadores. Desta forma, o 
caminhão é construído pelos integrantes da rede de cooperação, à medida que avança 
pela linha de montagem, como pode ser visto na Figura abaixo de Turban (2010).
3. Situação atual
Linha de montagem da VWB – Caminhões - Fonte: Turban et al. (2010)
Segundo o Turban (2010), na primeira parada no processo de montagem, alguns 
operários ficam responsáveis pela montagem do tanque de combustível, a caixa de 
marchas e caixas de direção. Enquanto que outros funcionários ficam responsáveis 
pela montagem dos eixos e freios, colocam as rodas e ajustam a pressão dos pneus. 
Enfim, todo o processo de montagem é feito por empresas parceiras.
Os funcionários da VWB fazem uma avaliação do caminhão depois de pronto. Os 
vários grupos nacionais ainda precisam se comunicar com suas matrizes, mas issoocorre raramente e isto é feito principalmente via e-mail.
O uso dos recursos da TI foi decisivo para promover esta transformação radical 
na forma de produzir os caminhões. A montadora dispõe de um sistema integrado de 
gestão (ERP), compartilhado por todos os demais fornecedores que operam no complexo 
industrial e acessado também pelas concessionárias, de onde emanam os pedidos de 
fornecimento dos caminhões para serem vendidos. O esquema de integração pode ser 
visto na Figura a seguir de Pinto (2015).
 
Esquema de integração de processos da VWB e de um fornecedor - Fonte: Francisco Pinto (2015)
4. Apresentação do Problema 
Com base no que vimos ao longo do texto, que relata sobre a cadeia de suprimento 
da Volkswagen Brasil, vimos que a mesma já aprimorou a qualidade e também, baixou 
os custos, tudo isso como um resultado do processo de que cada etapa, possuía o seu 
respectivo fornecedor responsável por ela. Com base no modelo adotado no Brasil, a 
empresa já pensa em exportar esse padrão para outras filiais, tais como a de Buenos 
Aires e a de Skoda, na República Tcheca.
Segundo Pinto (2015) o processo produtivo começa com uma reunião com 
representantes de cada empresa da rede, onde são estabelecidas as metas de produção 
para os próximos períodos. A partir disso, a empresa emite um processo que é chamado 
de Ordem de Produção (OP), que contém de forma detalhada, tudo o que a equipe deverá 
produzir, desde o modelo do caminhão a ser produzido no dia, como o material e assim 
por diante. Após essa definição é estabelecida metas a serem atingidas no período. 
O ERP possui também um módulo para realizar o gerenciamento do estoque. As 
requisições dos itens de almoxarifado para a produção são emitidas automaticamente, 
a partir das especificações da OP, fazendo as baixas relativas às saídas e emitindo, 
também automaticamente, as requisições de suprimentos para cobrir no estoque o que 
foi consumido2.
À medida que o caminhão avança na linha de montagem, os trabalhos já realizados 
a cada etapa são informados para atualização da OP, para que sejam dadas as devidas 
baixas, de maneira que ao final, o sistema ERP disponha de todos os dados relativos à 
produção, inclusive para possibilitar a geração dos indicadores de desempenho.
__________________ 
2 Neste modelo de produção, os estoques são mantidos em níveis mínimos, o que implica a necessidade de uma gestão eficaz do almoxarifado, inclusive 
junto aos fornecedores que estão fora do complexo industrial.
 
Referências
Com base no que foi relatado, faça uma análise crítica, por escrito, da aplicação 
da TI para a transformação do negócio de produção de caminhões da VWB, e depois 
responda às seguintes questões:
Lembre-se de justificar suas respostas com base no material visto na disciplina. O 
que importa realmente aqui não são as respostas propriamente ditas, mas sim os seus 
argumentos e justificativas.
TURBAN, Efraim; LEIDNER, Dorothy; MCLEAN, Ephraim; WETHERBE, James. Tecnologia 
da Informação para gestão: transformando os negócios na economia digital. 6. ed. 
Porto Alegre: Bookman, 2010.
 
Se compararmos com o modelo fordista, quais foram as transformações 
que o uso da TI proporcionou ao novo modelo de produção em rede de 
cooperação?
Por que foi necessário o uso de um ERP para todos os participantes 
da rede?
Esta solução integrada é necessária para os fornecedores que estão fora 
do complexo industrial? Por quê?
Qual é a diferença entre cadeia de suprimentos e cadeia de valor?
Em que aspectos do negócio a TI contribuiu para a redução dos custos 
da produção dos caminhões da VWB?
Quais podem ser os ganhos que a TI proporcionou para a VWB e 
seus fornecedores-parceiros?
Apresentação 
Estudo de 
Caso 02:
Estudos de Caso em ADS - Mercado 
e oportunidades de trabalho
2
O ano de 2014 foi um dos melhores anos para o mercado de TI. A manchete 
principal da entrevista do jornal Bom dia Brasil do dia 29/03/2014, mostrava a existência 
de 100.000 (cem mil) vagas só este ano. Nessa entrevista, o seguinte questionamento 
foi feito a um gerente de RH de uma grande empresa: isso é uma boa notícia para quem 
está precisando de emprego? Só que não era esse o foco da entrevista. A entrevista 
abordava a grande problemática por trás disso- o mercado tem uma grande escassez 
de mão de obra especializada para suprir muitas vagas. Os bons funcionários são muito 
disputados pelas empresas.
O ambiente de trabalho de empresas de tecnologia, geralmente é muito leve, pois 
para empresas que trabalham com a criatividade e atenção, o ambiente conta muito. 
O gerente de RH de uma das empresas pesquisadas informou que tem muitas vagas 
em aberto para desenvolvedores de sistemas bancários. O entrevistado diz existir 
dificuldade em encontrar profissionais fluentes em inglês e nas tecnologias exigidas. A 
empresa em questão tem a meta de dobrar o número de empregados no ano de 2014, 
contratando mais de quatrocentas pessoas.
 
Ao perguntar qual das áreas estava em maior defasagem, ele disse que a área 
de segurança bancária tem mais de cem vagas em aberto, dentre essas, cinco estão 
sendo procuradas a mais de um ano. Uma das grandes saídas no caso foi a busca de 
parcerias em escolas onde alguns funcionários da empresa passam a ser professores 
nas instituições.
Uma das grandes dificuldades na área de tecnologia é que a mesma muda com 
uma grande frequência e de maneira muito rápida, um funcionário da área de Tecnologia 
da Informação nunca pode se acomodar, o mesmo deve estar constantemente se 
atualizando.
Na entrevista, uma outra empresa foi mencionada- uma empresa do ramo de 
desenvolvimento de páginas na internet. O entrevistado relatou que em uma certa 
ocasião, um funcionário desenvolvia uma tecnologia que era pouco conhecida e por 
esse motivo, o mesmo teve de aprender a linguagem sozinho. O entrevistado continuou 
seu relato dizendo que o funcionário foi questionado sobre a sua conduta e que a sua 
resposta foi simples: “O ramo de desenvolvimento exige muito dele e que na internet 
é possível encontrar todo o subsídio necessário para o aprendizado”.
A área de TI , Tecnologia da Informação, é composta em sua maioria por jovens. 
Segundo o site EmpregoTi (2015), hoje no Brasil temos mais de duzentas mil vagas, 
entre preenchidas e vazias. O mesmo site afirma que ainda falta um pouco de incentivo 
por parte do governo para ampliação dessas vagas. Fato comum aos pensamentos dos 
empresários do ramo. Muitos empresários afirmam que o pais não cresce mais por falta 
de mão de obra especializada, e ainda é difícil encontrar a pessoa certa para a vaga 
em questão.
Ao ser questionado em uma entrevista sobre o perfil do profissional de TI, o 
presidente da Brasscom (Associação das empresas de tecnologia da informação) disse 
que o grande diferencial de um bom funcionário é a sua capacidade de concentração. 
Isso é interessante, pois não é o fato de saber muito sobre tecnologias ou ser bom 
em determinado ramo da TI. Geralmente, a capacidade de concentração é mérito das 
pessoas que leem muito.
 
O número de mais de duzentas mil vagas pode até assustar. Porém, hoje não 
há desenvolvimento de mercado, não há sucesso em uma organização que não passe 
por um setor de TI. Todos os ramos de mercado, necessitam de um profissional de TI, 
seja na parte de construção de software, o programa de computador propriamente 
dito, como também na parte da infraestrutura, que é o responsável por administração 
da rede, do cabeamento. Enfim, existe uma infinidade de seguimentos nessa área de 
Tecnologia da Informação.
O fato da área de Tecnologia da Informação não ser uma área regulamentada, 
o mercado tem absorvido tanto pessoas com o perfil de graduados como pessoas no 
perfil tecnológico. Hoje, não é só o fato de um funcionário ter uma graduação que o fará 
ganhar mais que um outro que só tem um curso tecnológico, o conhecimento envolvido 
é o fator diferencial.
Segundo o site (OlharDigital, 2015) foi feita uma previsão de saláriospara o 
mercado de TI em e foi constatado que só dois cargos devem sofrer redução salarial no 
mercado de tecnologia em 2015, de acordo com um estudo desenvolvido pela Robert 
Half que prevê aumentos de até 10,5% dentro do setor, com salários chegando aos R$ 
55 mil no próximo ano.
O Guia Salarial mostra que as únicas posições a serem desfavorecidas são a de 
analista de infraestrutura em telecomunicações júnior, que em grandes empresas 
terá o teto salarial reduzido de R$ 5 mil a R$ 4,5 mil (uma variação de -3%) e a de 
analista de ERP júnior, cuja base para quem está em pequenas ou médias empresas 
cairá de R$ 4 mil a R$ 3,5 mil (-2,5%).
Fora isso, quem atua como analista de negócios júnior provavelmente não terá 
alterações nos ganhos, pois é o único cargo em que não há previsão de variação – 
permanecerá entre R$ 3,5 mil e R$ 6 mil em pequenas e médias empresas e entre R$ 
4 mil e R$ 6,5 mil em grandes empresas.
A maior alteração será sentida nos bolsos dos analistas de negócios sênior, com 
altas de 10,5%. O teto em pequenas e médias empresas subirá de R$ 10 mil a R$ 12 
mil e, nas grandes, de R$ 12 mil a R$ 14 mil.
Já os maiores salários serão recebidos pelos diretores de TI (ou CIOs). O teto para 
quem ocupa o cargo em pequenas e médias empresas aumentará 4,5%, de R$ 35 mil a 
R$ 40 mil, enquanto os profissionais de grandes empresas manterão salários entre R$ 
25 mil e R$ 55 mil.
 
Hoje em dia, a qualificação de um profissional é um ponto fundamental para uma 
definição de uma carreira bem-sucedida. Assim, temos para cada setor especifico da 
área de informática uma certificação em particular. 
Dentre as várias certificações existentes no mercado, podemos citar como exemplo 
a certificação PMP. A sigla faz referência a Project Management Professional (Profissional 
de Gerência de Projetos). Essa certificação, por sua vez, é um documento emitido pelo 
PMI Project Management Institute. O objetivo da certificação é apresentar ao mercado 
gerentes de projetos competentes, visto que esse órgão tem um respeito internacional.
Com isso, o objetivo desse estudo de caso é motivá-lo na pesquisa de 3 diferentes 
certificações nas áreas que você deseja seguir, fazendo um paralelo entre elas.
EmpregoTi, 2015. Empregoti.com. [Online] 
Available at: www.empregoti.com 
[Acesso em 07 junho 2015].
OlharDigital, 2015. OlharDigital. [Online] 
Available at: http://olhardigital.uol.com.br/pro/noticia/confira-a-previsao-de-salarios-
para-o-mercado-de-ti-em-2015/45344 
[Acesso em 07 Junho 2015].
Apresentação do Problema
Referências 
 
Os objetivos dessa aula são introduzir alguns tópicos a respeito da 
Engenharia de Requisitos e discutir o processo envolvido em descobrir e 
documentar esses requisitos. Ao fim dessa aula você irá também:
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas
Engenharia de Requisitos (ER)
Introdução
Entender o conceito de usuários e sistema de requisitos e 
também o motivo que os requisitos deveriam ser escritos de 
diferentes formas.
Entender a diferença entre requisitos funcional e não funcional.
Entender como os requisitos devem ser organizados em um 
documento de requisitos de software.
Entender as principais atividades na engenharia de requisitos 
tais como elicitação, validação e análise, tal como a relação 
entre essas atividades.
Os requisitos de um sistema são as descrições de o que os sistemas 
devem fazer, os serviços que irá prover e as restrições que irá possuir. 
Esses requisitos devem refletir, diretamente, as necessidades do usuário/
cliente que demandou o sistema/serviço. O processo de levantamento dos 
requisitos, documentação e validação desses serviços e restrições é chamado 
de Engenharia de Requisitos (ER).
Nos próximos materiais iremos apreender um pouco sobre uma das 
áreas da engenharia de software. Qualquer dúvida não hesite em questionar 
o seu professor.
De acordo com Sommerville (2011), no que diz respeito 
a disciplina de requisito de software, podemos classificar os 
requisitos de duas formas, são elas:
Requisitos funcionais (RF): são toda as funcionalidades que 
o sistema deverá conter para que o mesmo seja atendido 
de acordo com a solicitação do usuário que demandou a 
atividade. Para esse tipo de requisito podemos dar como 
um exemplo as seguintes funcionalidades.
Documentação – onde informamos como o sistema 
deverá reagir para cada possível entrada; como 
o sistema DEVE se comportar em cada situação, 
determinada pelo usuário; bem como informar o 
que o sistema NÃO PODE fazer.
Completude – onde definimos todos os possíveis 
serviços a serem realizados.
Consistência – o documento não pode conter 
definições contraditórias.
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas - 
Engenharia de Requisitos (ER)
Requisitos funcionais e não funcionais1
 
Ainda no que diz respeito aos requisitos funcionais, 
Summerville (2011) afirma que é praticamente impossível 
conseguirmos criar um documento que atenda a todas 
funcionalidades informadas acima.
Requisitos não funcionais (RNF): nessa etapa devemos 
definir tudo que possa ser considerado uma propriedade 
necessária do sistema, bem como todas as possíveis 
restrições do mesmo. Um exemplo do que deve ser 
documentado nessa fase seria tudo relativo a segurança, 
desempenho, espaço em disco, dentre outros. A fase de 
elaboração dos RNF é considerada bem crítica, pois caso 
esse requisito seja mal elaborado ou não seja considerado 
na elaboração, isso poderá deixar o sistema inútil. Abaixo 
veremos algumas classificações desse requisito, são elas:
Requisito do produto – onde definimos todo o 
comportamento do software, como por exemplo o 
desempenho esperado do mesmo.
Requisitos organizacionais - são todos os requisitos 
que atendem aos procedimentos adotados em 
uma organização, como por exemplo, os padrões 
adotados por uma determinada empresa.
Requisitos externos – provenientes do ambiente 
onde o sistema será inserido, nesse caso podemos 
citar alguma legislação que regule o meio onde o 
mesmo será inserido.
Sommerville (2011), informa em sua obra que a diferença 
entre os requisitos RF e o RNF, não é tão simples, conforme 
a definição acima, pode ocorrer facilmente um erro de 
interpretação do um analista que define um requisito de 
um tipo e quando for implementar o mesmo verificar que 
se trata de um outro tipo de requisito.
Requisitos funcionais
 
Para Sommerville (2011), os “requisitos funcionais de um 
sistema descrevem o que ele deve fazer. Eles dependem do tipo 
de software a ser desenvolvido, de quem são seus possíveis 
usuários e da abordagem geral adotada pela organização ao 
escrever os requisitos”.
Os requisitos funcionais podem ser definidos de forma bem 
abrangente, abordando tudo o que o sistema deve fazer ou ser 
mais detalhado. Nesse tipo de documento, devemos informar 
todos os detalhes de forma precisa.
Geralmente, na prática para sistemas grandes e complexos, 
é impossível alcançar completude e consistência dos requisitos. 
Podemos definir como alguns exemplos de requisitos funcionais 
as seguintes situações:
Um dos principais papéis nessa fase é o exercido pelo 
stakeholder, que é a pessoa ou papel que, de alguma maneira, 
é afetado pelo sistema. Os stakeholders têm necessidades 
diferentes.
Quão maior for o sistema, mais papéis ele terá envolvido, 
ou seja, mais stakeholders haverá no sistema. Por isso, é um 
grande erro deixar toda validação e levantamento dos requisitos 
envolvidos nas mãos de uma única pessoa. É necessário que 
haja mais envolvidos para que não ocorra nenhum viés nessa 
fase, pois trata-se de uma fase crítica do sistema.
Requisitos funcionais
O usuário pode pesquisar todo ou um subconjunto do banco de dados.
O sistema deve oferecer telas apropriadas para o usuário ler documentos 
armazenados.
Cada pedido deve ser associado a um identificador único, o qual o usuário 
pode copiar para a área de armazenamento permanente da conta.
 
Ainda segundo Sommerville (2011), requisitos não 
funcionais(RNF) são aqueles que não estão diretamente 
envolvidos com os serviços específicos oferecidos pelo 
sistema a seus usuários. Eles podem estar relacionados as 
propriedades emergentes do sistema, como confiabilidade, 
tempo de resposta e ocupação de área. Uma alternativa a 
esse cenário seria os requisitos definirem restrições sobre 
a implementação do sistema, como as capacidades dos 
dispositivos E/S ou as representações de dados usadas nas 
interfaces com outros sistemas. 
Sommerville (2011) afirma que uma das grandes 
dificuldades relatadas a definição de um requisito não funcional 
é o fato de traçarmos uma relação entre o requisito funcional que 
implementa o requisito não funcional. Como exemplo podemos 
ver o que o autor trata, que seria o caso de uma impressão de 
um determinado relatório e nele todos os componentes que 
formatam o mesmo, seriam os requisitos funcionais. 
Com isso temos, como exemplo o caso de um requisito 
não funcional poder gerar vários requisitos funcionais para que 
o mesmo seja implementado, como em um sistema bancário, 
por exemplo, podemos listar como um possível RNF o fato 
de termos agregado a ele uma segurança que impeça que os 
dados bancários do mesmo sejam divulgados sem uma devida 
autorização. Para que isso seja implementado é necessária a 
implementação de uma série de RF.
Requisitos não funcionais
 
Pressman (2006) classifica em sua obra os RNF, conforme 
podemos analisar na tabela abaixo:
Tipo de requisito Definição 
Requisitos de produtos Tem por objetivo detalhar a forma que o produto 
deverá se comportar. Para isso podemos citar a 
portabilidade, tempo de execução, dentre outros. 
Requisitos da 
organização 
Detalha as particularidades de uma organização 
como um todo, como por exemplo os padrões 
adotados pela mesma. 
Requisitos externos Detalha todos os fatores relativos ao ambiente 
onde o sistema está inserido, como legislação que 
envolva a atividade do software, uma localização 
geográfica, entre outros. 
Requisitos de facilidade 
de uso 
O sistema deve ser simples o suficiente para que, 
com um treinamento o usuário tenha a 
capacidade de utilizar o mesmo. 
Requisitos de eficiência Onde são definidas métricas que garantem que o 
sistema irá operar com qualidade. 
Requisito de 
confiabilidade 
Local onde será definido as restrições que o 
software deverá atender, como por exemplo um 
tempo máximo de espera em uma consulta. 
Requisitos de 
portabilidade 
Onde será definida as plataformas que o software 
irá ser executado. 
Requisitos de entrega Onde são definidos os marcos, como por exemplo, 
uma determinada atividade deverá ser encerrada 
na próxima segunda-feira 
Requisitos de 
implementação 
Local onde será definido características técnicas 
do sistema, como por exemplo a linguagem que o 
mesmo deverá ser desenvolvido. 
Requisitos de padrões Definem os padrões a serem utilizados no projeto 
como um todo. 
Requisitos de 
interoperabilidade 
Define as restrições do sistema, como por 
exemplo que o mesmo deverá se conectar 
somente com o SQL Server. 
Requisitos éticos O sistema deverá respeitar os níveis de acesso 
para uma determinada informação e guardar 
sigilo da mesma. 
Requisitos legais O sistema deverá atender as leis que regem o 
ambiente onde o sistema será inserido. 
Requisitos de integração Informa com quais aplicações um determinado 
sistema irá ser integrado. 
 
 
Todos os autores concordam no fato de que os RNFs devem 
possuir, em sua maioria, métricas que possam auxiliar na busca 
da qualidade. Para auxiliar a definição dessas métricas, temos 
alguns pontos a ser analisado, conforme tabela abaixo.
BECK, k. “Embracing Change with Extreme Programming.” 
IEEE Computer, 1999: 32(10), 70-8.
IEEE. “IEEE Recommended Practice for Software 
Requirements Specifications.” IEEE Software Engineering 
Standards Collection, 1998.
MEDA, Marcos. Você pode ser líder. 1ª. São Paulo: Schoba, 
2013.
PRESSMAN, R. S. “Software Engineering: a practioner´s 
approach.” European Edition, 1994.
PRESSMAN, Roger. Engenharia de Software. 6ª. McGraw-
Hill, 2006.
ROBERTSON, S. Mastering the Requirements Process. 
Harlow: Addison-Wesley, 1999.
SOMMERVILLE, Ian. Engenharia de Software. 9ª. São 
Paulo: Pearson, 2011.
Referências 
Métrica Definição 
Velocidade Onde devemos considerar o tempo de processamento das 
transações; qual o tempo que o usuário considera aceitável 
para a resposta de uma determinada requisição bem como 
o tempo em que o usuário irá ficar acessando a tela. 
Facilidade de 
uso 
Deverá ser considerado todo o tempo necessário para ser 
disponibilizado em treinamento; informar quantas 
mensagens/telas de auxilio o sistema possui. 
Confiabilidade Nesse ponto o documento deverá conter uma descrição 
detalhada dos problemas que relatam a respeito de 
confiabilidade, como o tempo médio de falha, probabilidade 
de indisponibilidade, as taxas de ocorrência de falha bem 
como a taxa de disponibilidade do mesmo. 
Robustez Descrevemos atividades que garantam a robustez do 
sistema, como o tempo necessário para reinício após uma 
falha, porcentagem de eventos que causam falhas, dentre 
outros. 
 
 
O documento de requisitos de um software é onde 
colocamos todas as especificações relativas ao mesmo. Por 
meio desse documento, que geralmente é feito pelo analista de 
sistemas e passado para a equipe de desenvolvimento. Caso 
o documento seja bem construído ele deverá conter todos os 
detalhes relativo a atividade a ser implementada. Com isso, 
uma vez que o programador/desenvolvedor do software, tenha 
em mãos toda a documentação o mesmo não necessitará de 
consultar o usuário solicitante e passará a dedicar o seu tempo 
para o desenvolvimento da atividade documentada.
Segundo Sommerville (2011), é uma boa prática que um 
documento de requisito possua a descrição de uma atividade 
em particular, fazendo assim que caso tenha outra atividade 
a ser desenvolvida, deverá ter um documento de requisito 
específico para essa outra atividade.
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas - 
Engenharia de Requisitos (ER)
Documento2
 
A grande vantagem de possuirmos um documento desse 
tipo é o caso de, por exemplo, uma empresa ter um funcionário 
que trabalhe há muito tempo e ele passe em um concurso e, 
por consequência, pede para sair da organização. Neste caso, 
a empresa terá que contratar um novo funcionário, sendo que 
este, naturalmente, não irá trabalhar da mesma maneira que 
o funcionário que saiu. Mas, se possuirmos um documento 
contendo todos os detalhes do sistema, bem como todas as 
regras de negócio, o funcionário novato irá ter uma curva de 
aprendizagem bem menor do que teria caso esse documento 
não existisse. 
As empresas que se baseiam em métodos de 
desenvolvimento ágeis não costumam possuir documentos 
desse tipo. Elas afirmam já que os requisitos mudam de 
uma forma tão rápida, o tempo gasto para a construção do 
documento será em vão, pois assim que o mesmo finalizar 
a construção do documento esse já estará desatualizado. Ao 
invés de um documento formal de requisito, alguns autores, 
tais como Beck (1999) tratam sobre uma metodologia ágil, 
chamada de Extreme Programming (XP). 
Ela trata de uma coleta de requisitos do usuário de forma 
incremental e as escreve em cartões como histórias do usuário. 
Assim, o usuário poderá priorizar quais requisitos deverão ser 
primeiramente implementados na próxima versão do sistema.
 
A metodologia Ágil é muito interessante. Imagine um 
sistema onde a mudança dos requisitos não seja algo muito 
constante, como por exemplo podemos verificar o caso de 
um sistema onde o objetivo central do mesmo seja controlar 
o estoque de um determinado departamento, nesse caso, os 
requisitos são bem estáveis, não sofrem muitas alterações, 
com isso podemos manter o padrão de desenvolvimentos de 
documentos para especificar as atividades a serem desenvolvidas 
no mesmo. Agora se o sistema a ser desenvolvido, sofrer 
constantes alterações do meioem que ele esteja inserido, seja 
por meio de legislação que se altere, ou qualquer outro fator, o 
que a metodologia ágil afirma faz sentido, pois o documento irá 
ficar em constante alteração. 
Podemos embasar essa afirmativa por meio de Sommerville 
(2011), onde ele afirma que a metodologia ágil é válida para 
sistemas que possuem uma grande instabilidade nos seus 
requisitos e que, nos demais casos, devemos utilizar o padrão 
de levantamento de requisitos tradicional.
É no documento de requisitos que devemos especificar 
todas as funcionalidades que serão implementadas no sistema, 
além de informarmos quais são as qualidades que desejamos 
que o sistema possua. 
Um documento de requisitos é considerado bem elaborado 
se o mesmo for facilmente interpretado pelo solicitante da 
melhoria, o stakeholder, como não conter itens inconsistentes 
e passiveis de dúvidas. Os possíveis leitores do documento, 
serão tanto o solicitante, como o desenvolvedor do sistema, por 
tanto, não deve conter termos muito técnicos, voltados para o 
desenvolvimento do sistema, que será de difícil interpretação do 
usuário solicitante, bem como conter termos técnicos, do nicho 
particular do usuário solicitante, que seja de difícil interpretação 
de um desenvolvedor. A regra é tentar que o mesmo atinja 
um meio termo. Nesse caso, os termos técnicos, se necessário 
ser incluído, devem ser bem detalhados, para que ambos os 
perfis consigam entender. A equipe de teste, irá montar os seus 
cenários de teste a partir do documento de requisito.
 
Como já foi dito, o objetivo central de um documento de 
requisito é especificar todas as particularidades do sistema a 
ser desenvolvido. Com isso, podemos definir como parte das 
atribuições desse documento: Especificação contendo uma 
visão geral do sistema; detalhamento de requisitos funcionais 
e não funcionais e um documento de apoio.
É importante perceber a importância do documento de 
requisitos como determinante para o sucesso de um projeto. 
Ele identifica quais funcionalidades fazem parte ou não do 
escopo do sistema. 
Ainda segundo (Sommerville 2011) a estrutura de um 
documento de requisitos segue a seguinte formação:
Referências: 
Capítulo Descrição 
Prefácio Deve definir os possíveis leitores do documento e descrever seu 
histórico de versões, incluindo uma justificativa para a criação de 
uma nova versão e um resumo das mudanças feitas em cada 
versão. 
Introdução Deve descrever a necessidade para o sistema. Deve descrever 
brevemente as funções do sistema e explicar como ele vai 
funcionar com outros sistemas. Também deve descrever como o 
sistema atende aos objetivos globais de negócio ou estratégicos 
das organizações que encomendou o software. 
Glossário Deve definir os termos técnicos usados no documento. Você não 
deve fazer suposições sobre a experiência ou o conhecimento do 
leitor. 
Definição de requisitos 
de usuário 
Deve descrever os serviços fornecidos ao usuário. Os requisitos 
não funcionais de sistema também devem ser descritos nessa 
seção. Essa descrição pode usar a linguagem natural, diagramas 
ou outras notações compreensíveis para os clientes. 
Arquitetura do sistema Deve apresentar uma visão geral em alto nível da arquitetura do 
sistema previsto, mostrando a distribuição de funções entre os 
módulos do sistema. 
Especificações de 
requisitos do sistema 
Deve descrever em detalhes os requisitos funcionais e não 
funcionais. Se necessário, também podem ser adicionados mais 
detalhes aos requisitos não funcionais. Interfaces com outros 
sistemas podem ser definidas. 
Modelos do sistema Pode incluir modelos gráficos do sistema que mostram os 
relacionamentos entre os componentes do sistema, o sistema e 
seu ambiente. Exemplos de possíveis modelos são modelos de 
objetos, modelos de fluxo de dados ou modelos semânticos de 
dados. 
Evolução do sistema Deve descrever os pressupostos fundamentais em que o sistema 
se baseia, bem como quaisquer mudanças previstas, em 
decorrência da evolução de hardware, de mudanças nas 
necessidades do usuário etc. Essa seção é útil para projetistas de 
sistemas, pois pode ajuda-los a evitar decisões capazes de 
restringir possíveis mudanças futuras no sistema. 
Apêndices Deve fornecer informações detalhadas e específicas relacionadas à 
aplicação em desenvolvimento, além de descrições de hardware e 
banco de dados, por exemplo. Os requisitos de hardware definem 
as configurações mínimas ideais para o sistema. Requisitos de 
banco de dados definem a organização lógica dos dados usados 
pelo sistema e os relacionamentos entre esses dados. 
Índice Vários índices podem ser incluídos no documento. Pode haver, 
além de um índice alfabético normal, um índice de diagramas, de 
funções, entre outros pertinentes. 
 
Formatação requisitos - Fonte: Sommerville 
 
Referências: 
BECK, k. “Embracing Change with Extreme Programming.” 
IEEE Computer, 1999: 32(10), 70-8.
IEEE. “IEEE Recommended Practice for Software 
Requirements Specifications.” IEEE Software Engineering 
Standards Collection, 1998.
MEDA, Marcos. Você pode ser líder. 1ª. São Paulo: Schoba, 
2013.
PRESSMAN, R. S. “Software Engineering: a practioner´s 
approach.” European Edition, 1994.
PRESSMAN, Roger. Engenharia de Software. 6ª. McGraw-
Hill, 2006.
ROBERTSON, S. Mastering the Requirements Process. 
Harlow: Addison-Wesley, 1999.
SOMMERVILLE, Ian. Engenharia de Software. 9ª. São 
Paulo: Pearson, 2011.
 
O termo utilizado para a elaboração de um documento 
de requisito é especificação de requisitos do sistema. A grande 
dificuldade dessa atividade, conforme dito anteriormente, é 
construir um documento que seja simples o suficiente, para 
ser interpretado por todas as partes envolvidas e que seja livre 
de erros de interpretação, bem como completo e consistente. 
Ou seja, na prática é quase que impossível construir um 
documento tão perfeito assim, isso porque, na grande maioria 
das vezes o próprio usuário, ou stakeholder, não tem a clareza 
do que de fato será solicitado.
O documento de requisitos, não deve ter detalhes 
técnicos, que são importantes para o desenvolvedor, tal como 
a arquitetura que será utilizada, o padrão de programação que 
será implementado, enfim, o mesmo deve ser bem simples, no 
que diz respeito a termos e jargões técnicos. Sabendo disso, é 
importante que nesse documento possua as especificações da 
camada externa do sistema.
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas - 
Engenharia de Requisitos (ER)
Especificação de Requisitos3
 
A palavra “elicitação” não existe na língua portuguesa, 
mas foi criada e tem sido utilizada por vários autores 
Pressman (1994) englobando o significado dos verbos elicitar 
(fazer sair, extrair, trazer à tona a verdade), clarear, extrair e 
descobrir. Assim, uma definição sucinta de elicitação é obter 
e tornar explícito o máximo de informações possíveis para o 
conhecimento de um objeto em questão.
Por isso, é nessa fase de elicitação que o analista 
responsável pela coleta dos requisitos, ou engenheiro de 
requisitos, deverá procurar ter um conhecimento do domínio 
do problema, para que assim o mesmo consiga extrair de 
forma exata o requisito necessário para solução do problema. 
Com isso, para que essa coleta do requisito seja feita da 
melhor forma é importante notar três pontos, que são 
relatados por Sommerville (2011), são eles: identificação das 
fontes de informação; coleta de fatos de comunicação além de 
ferramentas, pessoal e métodos.
A primeira dificuldade é a identificação da fonte de 
informação, portanto é necessário fazer uma análise detalhada 
em todo o domínio do sistema, identificando quem são os 
usuários, como foi elaborado o Plano Diretor de Informática 
(PDI), bem como todos os documentos que se referem ao 
domínio do sistema em questão.
Na atividade de coleta de fatos, usualmente são feitas 
entrevistas com os clientes, são consultados os materiais 
existentes que descrevem os objetivos e desejos da 
organização, e também é pesquisadaa existência de sistemas 
similares para uma posterior análise. É importante observar 
que o uso apenas de entrevista não é suficiente para obter 
todas as informações necessárias. 
 
Outras técnicas importantes para a coleta de fatos sobre um 
sistema são: leitura de documentos, observação, questionário, 
análise de protocolos, participação ativa dos agentes (autor 
e usuário), enfoque antropológico, reuniões, reutilizações e 
recuperação (engenharia reversa) do projeto do software.
Para essa atividade de coleta de informação, há várias 
técnicas que os engenheiros de requisito utilizam, dentre 
elas podemos citar: levantamento orientado a ponto de vista, 
etnografia, workshop, prototipagem, entrevistas, questionários, 
brainstorming, Joint Application Desing, conhecida pela sigla de 
JAD, dentre outras. Nessa aula iremos focar apenas na técnica 
baseada em questionário.
A técnica de coleta de dados baseada em questionários é 
mais utilizada quando os usuários chaves de um determinado 
domínio do sistema estão em localidades distintas e distantes, 
não podendo ter entrevistas individuais com os mesmos. Nesse 
caso, vários tipos de questionário podem ser utilizados, porém 
o grande detalhe da elaboração do questionário é que o mesmo 
deve ser elaborado de uma forma que facilite o entendimento do 
leitor e assim otimize o tempo de resposta do mesmo. Quando 
o questionário estiver sendo elaborado, é de suma importância 
saber que tipo de informação desejamos coletar do usuário. As 
questões devem ser elaboradas de forma bem simples, tendo 
tanto questões de múltipla escolha, como alguns itens abertos. 
Por fim, é de suma importância que, no questionário possua um 
texto redigido por alguém da alta-gestão da organização que 
enfatize a importância da participação, no que diz respeito as 
respostas do questionário.
 
Para que a elicitação tenha sucesso é fundamental que 
os engenheiros de requisitos se comuniquem eficazmente 
com os clientes ou pessoas (especialistas) que entendem o 
problema. O engenheiro de requisitos precisa se envolver 
com o trabalho do cliente e/ou especialistas no domínio, se 
envolver com os funcionários, observar, aprender e questionar.
Pressman (1994) afirma que, o conteúdo do documento 
de requisitos será utilizado em todas as fases seguintes, tais 
como desenvolvimento e controle de qualidade, onde será 
validado por meio dos testes. 
Na engenharia de software, o uso da linguagem 
natural é a maneira mais utilizada na descrição dos 
requisitos necessários em um determinado sistema. Por 
isso a necessidade de clareza na descrição das atividades. 
O entendimento do conteúdo do documento, dependo muito 
do conhecimento relativo ao seu leitor, portanto é necessário 
muito cuidado ao elaborar esse documento.
Com o objetivo de buscar uma melhoria na clareza 
da elaboração desse documento, evitando tirar todos os 
possíveis termos que possam vir a gerar alguma dúvida na 
interpretação, vamos listar algumas recomendações contidas 
na obra de Sommerville (2011), são elas:
Devemos definir um template, um documento padrão, 
onde nele iremos definir todo o padrão de formatação. 
Isso garante a omissão de alguns detalhes importantes 
a serem avaliados.
Especificação em linguagem natural Referências: 
 
É fundamental a clareza na distinção de requisitos 
obrigatórios e requisitos desejáveis. Para os obrigatórios, 
a sugestão é o uso do verbo DEVER, para enfatizar a 
obrigação do requisito ser implementado.
Devemos ser muito claros na definição de uma atividade, 
não deixando nenhum termo técnico, sem a devida 
explicação. Para isso é importante que seja evitado o 
uso de jargões, siglas, dentre outros.
Sempre que possível, tente associar uma lógica a 
cada um dos requisitos de usuário. Essa justificativa 
deve explicar por que o requisito foi incluído, e é 
particularmente útil quando os requisitos são alterados, 
uma vez que pode ajudar a decidir sobre quais mudanças 
seriam indesejáveis.
Referências: 
BECK, k. “Embracing Change with Extreme Programming.” 
IEEE Computer, 1999: 32(10), 70-8.
IEEE. “IEEE Recommended Practice for Software 
Requirements Specifications.” IEEE Software Engineering 
Standards Collection, 1998.
MEDA, Marcos. Você pode ser líder. 1ª. São Paulo: Schoba, 
2013.
PRESSMAN, R. S. “Software Engineering: a practioner´s 
approach.” European Edition, 1994.
PRESSMAN, Roger. Engenharia de Software. 6ª. McGraw-
Hill, 2006.
ROBERTSON, S. Mastering the Requirements Process. 
Harlow: Addison-Wesley, 1999.
SOMMERVILLE, Ian. Engenharia de Software. 9ª. São 
Paulo: Pearson, 2011.
 
Apresentação 
Estudo de 
Caso 03:
Estudos de Caso em ADS - 
Especificando um negócio
3
Conforme listado na aula relativa a Engenharia de Requisitos, vimos a grande 
importância de um requisito ser bem desenvolvido, bem como o impacto que irá 
ocasionar em um requisito mal elaborado. O mercado de TI hoje, tem carência de bons 
analistas e há bons salários aguardando bons profissionais. 
Nessa semana iremos simular a atividade de um analista de requisito, onde dado 
uma situação de mundo, você deverá extrair os requisitos funcionais (RF), requisitos 
não-funcionais (RNF), dentre outros.
 
O caso a ser especificado é o de Controle de Reservas de um Hotel, que deverá ser 
utilizado por uma rede de hotéis, oferecendo uma interface totalmente voltada a WEB. 
O sistema deverá disponibilizar ao hotel uma plataforma que permita com que 
os usuários, por meio de terminais a serem instalados ao longo dos espaços comuns 
do hotel, possam realizar operações básicas, como a reserva ou o cancelamento de 
um apartamento, através da WEB. 
Esse sistema também deverá permitir a comunicação com os outros hotéis da 
mesma rede, no qual o usuário possa consultar a disponibilidade de vagas. Este sistema 
deverá fazer uma interface com outros dois sistemas internos do hotel, relacionado a 
controle de restaurante de forma geral e também irá gerenciar o controle de tarifação 
de telefone.
O objetivo central desse sistema é descentralizar o controle das atividades 
básicas de um hotel, onde deixará tudo a cargo do cliente, não mais precisando de um 
funcionário com dedicação exclusiva para isso.
Dado o problema acima, elabore o documento de requisito, nos moldes do que 
estudamos na aula passada e que atendam ao que é solicitado. No caso de dúvidas, 
entre em contato com o seu professor.
Contextualização
Apresentação do problema
 
Os bancos de dados e os sistemas de bancos de dados se tornaram 
componentes essenciais no cotidiano da sociedade moderna. No decorrer 
do dia, a maioria de nós se depara com atividades que envolvem interação 
com os bancos de dados. Por exemplo, se formos ao banco para efetuarmos 
um depósito ou retirarmos dinheiro, se fizermos reservas em um hotel 
ou para compra de passagens aéreas, se acessarmos o catálogo de uma 
biblioteca informatizada para consultar uma bibliografia, ou se comprarmos 
produtos – como livros, brinquedos ou computadores – de um fornecedor 
por intermédio de sua página web, muito provavelmente essas atividades 
envolverão uma pessoa ou um programa de computador que acessará um 
banco de dados. Até mesmo os produtos adquiridos em supermercados, 
em muitos casos, atualmente, incluem uma atualização automática do 
banco de dados que mantém o controle do estoque disponível nesses 
estabelecimentos.
Estudos de Caso em Análise e 
Desenvolvimento de Sistemas
Temas:
Introdução 
Introdução a banco de dados
Vantagens do SGBD
Modelo de Dados, um breve histórico do banco de dados
Essas interações são exemplos do que podemos denominar aplicações 
tradicionais de banco de dados, no qual a maioria das informações que são 
armazenadas e acessadas apresenta-se em formatos textual ou numérico. 
Nos últimos anos, os avanços tecnológicos geraram aplicações inovadoras e 
interessantes dos sistemas de banco de dados.
Nos próximos materiais iremos apreender um pouco sobre banco de 
dados, entenderemos a sua real necessidade e observaremos