USF_EAD_U2_Engenharia_de_software

Prévia do material em texto

22
Engenharia de Requisitos
2
UNIDADE 2
ENGENHARIA DE REQUISITOS
INTRODUÇÃO
Para compreender os processos da Engenharia de Requisitos torna-se fundamental 
observar e identificar os diversos tipos de requisitos e a sua importância no desenvolvi-
mento de software. 
Há diversas definições sobre requisitos de software e como são expressas, mas todas 
elas convergem para o fato de os requisitos serem a base de comunicação conceitual 
para o entendimento do problema a ser resolvido. Esses requisitos proporcionam sub-
sídios para a estruturação do software a ser desenvolvido ou daquele que vai passar 
por manutenção.
Essa unidade apresenta também o detalhamento das técnicas de levantamento de re-
quisitos que podem ser utilizadas para entendermos qual será, de fato, o problema que 
estamos tentando resolver ao estudarmos as necessidades dos clientes.
1. REQUISITOS DE SOFTWARE
O desenvolvedor de software ou aplicativo vai iniciar o desenvolvimento de uma solução a 
partir do levantamento das necessidades dos clientes ou usuário, que podem surgir a par-
tir da criação de um novo e inédito produto ou da manutenção de um software já existente.
Requisito é uma condição necessária para a obtenção de certo objetivo ou para o pre-
enchimento de certo fim.
Requisitos para um sistema de software é a descrição das funções e restrições que 
o produto a ser desenvolvido deve possuir.
Engenharia de Requisitos é o processo de descobrir, analisar, documentar e verificar 
essas funções e restrições.
1.1 TIPOS DE REQUISITOS
 ` Do usuário: declarações, em língua natural e/ou diagramas, sobre as funções 
que o sistema deve fornecer e restrições sob as quais deve operar. São requisi-
tos abstratos de alto nível.
23
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
 ` Do sistema: funções e restrições do sistema, de uma forma mais detalhada, são 
normalmente classificadas como funcionais e não funcionais.
 ` Especificação do projeto: associa a engenharia de requisitos às atividades de pro-
jeto. É uma descrição abstrata do projeto, serve como base para o projeto e para 
a implementação e assim acrescenta mais detalhes à especificação de requisitos.
1.2 REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS
Para entender melhor esses tipos de requisitos vamos explicar o que se entende por 
requisitos funcionais e não funcionais e a seguir uma melhor caracterização de como 
podemos classificar os requisitos.
Requisitos funcionais
São aqueles diretamente ligados à funcionalidade do software, isto é, como o sistema 
deve reagir às entradas específicas ou como deve se comportar em determinadas situ-
ações. Em alguns casos podem declarar o que o sistema não deve fazer e dependem 
do tipo de sistema a ser desenvolvido e dos usuários.
Requisitos funcionais são descritos em diferentes níveis de detalhes como telas apro-
priadas e diferentes formatos. Mesmo tratando-se de um documento completo e consis-
tente, na prática é quase impossível atingir essa meta, pois à medida que os problemas 
são descobertos, o documento de especificação deve ser corrigido.
Por exemplo, o sistema de biblioteca da universidade permite:
 ` Pedir livros e documentos a outras universidades;
 ` Buscar todo o conjunto inicial no banco de dados ou selecionar um subconjunto;
 ` Fornecer formas apropriadas para ler documentos no repositório de documen-
tos; e
 ` Alocar um único identificador a cada pedido.
Requisitos não funcionais
São aqueles que não dizem respeito diretamente às funções específicas do sistema. 
Em vez disso, podem estar relacionados às propriedades do sistema como confiabili-
dade, tempo de resposta, restrições sobre o processo, padrões etc. Como exemplo os 
requisitos não funcionais podem ser:
 ` Dependendo do resultado do teste, somente o supervisor pode efetuar a entrada 
do resultado do teste de um paciente;
 ` O sistema deve emitir um recibo para o cliente até oito segundos após a transação; e
 ` As ferramentas CASE a serem utilizadas na modelagem do software serão 
(Nome do Software).
24
Engenharia de Requisitos
2
1.3 CLASSIFICAÇÃO DOS REQUISITOS
Agora vamos entender melhor como classificar os requisitos.
Requisitos do usuário
Devem descrever os requisitos funcionais e não funcionais de modo compreensível 
pelos usuários sem conhecimento técnico detalhado. Especificam o comportamento 
externo do sistema, evitando características de projeto e podem ser escritos em língua 
natural, formulários e diagramas intuitivos simples. Lembrando que o uso da de língua 
natural pode trazer falta de clareza, ambiguidade e falta de precisão, dando origem a 
um documento de difícil leitura caso é comum uma certa confusão entre os requisitos 
funcionais e não funcionais e assim os objetivos do sistema e as informações sobre o 
projeto podem não ficar claramente definidos.
Requisitos do produto
Comportamento do produto, como desempenho, memória, confiabilidade, taxa aceitá-
vel de falha, portabilidade e facilidade de uso.
Requisitos organizacionais 
São as políticas e os procedimentos nas organizações do cliente e do desenvolvedor 
contendo padrões de processo, requisitos de implementação, como a linguagem ou 
método de projeto, requisitos de entrega do produto e documentos associados.
Requisitos externos 
São fatores externos ao sistema e ao processo de desenvolvimento como por exemplo 
a interoperabilidade com outros sistemas, requisitos legais, requisitos éticos. Exemplos:
 ` Dependendo do resultado do teste, somente o supervisor pode efetuar a entrada 
do resultado do teste de um paciente.
 ` O sistema deve emitir um recibo para o cliente até oito segundos após a transação.
 ` O Sistema de Aviação deve atender ao requisito de confiabilidade previsto na 
Resolução ANEC 999.
 ` O sistema de tempo real deve atender ao requisito de desempenho; do contrário 
as funções de controle não operarão corretamente.
 ` Tipos de ferramentas CASE e descrição do processo a ser seguido.
Requisito verificável 
Considerando que o sistema deve ser fácil de utilizar e organizado, de modo que os er-
ros dos usuários sejam minimizados, os controladores experientes devem ser capazes 
de utilizar todas as funções do sistema, receber treinamento em um breve momento, se 
necessário, e assim o número médio de erros cometidos por usuários experientes não 
deve exceder a dois por dia.
25
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
Requisitos de domínio 
Têm origem no domínio de aplicação e refletem características desse domínio. Podem 
ser novos requisitos funcionais, podem restringir requisitos funcionais existentes, ou ainda 
estabelecer como realizar cálculos específicos. Exemplo para o sistema de biblioteca:
 ` Deve haver uma interface padrão com o usuário para todos os bancos de dados, 
que terá como base o padrão Z39.50;
 ` Em razão das restrições referentes a direitos autorais, alguns documentos de-
vem ser imediatamente excluídos após serem fornecidos; 
 ` Alguns documentos serão impressos localmente no servidor do sistema para 
serem encaminhados ao usuário ou direcionados para uma impressora de rede.
2. DOCUMENTO DE REQUISITOS DE SOFTWARE 
2.1. O QUE É
Trata-se de uma declaração oficial do que é exigido dos desenvolvedores do sistema. 
Inclui os requisitos do usuário para um sistema e uma especificação detalhada dos re-
quisitos do sistema. O documento tem um número diversificado de usuários.
2.2. QUEM FAZ O QUÊ 
 ` Clientes do sistema: especificam e verificam se os requisitos atendem as suas 
necessidades e especificam mudanças;
 ` Gerentes: usam o documento para planejar o processo de desenvolvimento;
 ` Engenheiros de software: compreendem como o sistema deverá ser desenvolvido;
 ` Engenheiros de teste: desenvolvem os testes de validação
 ` Engenheiros de manutenção: compreendem o sistema e as relações entre 
suas partes.
2.3. FORMATO SUGERIDO PARA O DOCUMENTO DE REQUISITOS
I. Introdução: descreve a necessidade do sistema e brevemente suas funções e como 
deve operarcom outros sistemas. Descreve também como o sistema se ajustar aos 
negócios em geral e aos objetivos estratégicos da organização que está encomendan-
do o software.
II. Glossário: em que são definidos os termos técnicos utilizados no documento e 
aqui não se deve fazer suposições sobre a experiência ou conhecimento do leitor.
26
Engenharia de Requisitos
2
3. PROCESSOS DA ENGENHARIA DE REQUISITOS
Engenharia de Requisitos é o processo de descobrir, analisar, documentar e verificar os 
requisitos de um determinado sistema. Em outros termos, é uma ação da engenharia 
de software que se inicia durante a atividade de comunicação e continua na fase de 
modelagem, estabelecendo assim uma base importante para o projeto e construção do 
software.
Se houver falhas na fase de engenharia de requisitos o resultado do produto pode não 
atender às necessidades do cliente. Caso isso aconteça, a fase deve ser adaptada 
às necessidades tanto do processo, do projeto e do produto quanto das pessoas que 
estão realizando o trabalho. As tarefas realizadas na engenharia de requisitos devem 
ser desenvolvidas de maneira iterativa entre a equipe do projeto e todos os envolvidos.
A engenharia de requisitos se inicia com os envolvidos no projeto, que podem ser ge-
rentes, clientes e usuários, quando é definida a necessidade do negócio, são descritos 
os cenários dos usuários, delineadas as funções e os recursos e identificadas as restri-
ções de projeto. A engenharia de requisitos abrange as seguintes tarefas: concepção, 
levantamento, elaboração, negociação, especificação, validação e gerenciamento de 
requisitos. Algumas destas tarefas ocorrem em paralelo e podem até ter continuidade 
durante o projeto.
III.
VI.
Definição dos requisitos do usuário: descreve os serviços fornecidos para o 
usuário e os requisitos não funcionais do sistema. Pode-se utilizar língua natural, 
diagramas ou outras notações que sejam compreendidas pelos clientes.
IV.
VII.
Especificação dos requisitos do sistema: descreve os requisitos funcionais e 
não funcionais com mais detalhes e podem ser definidas interfaces, isto é, como 
o software interage com as pessoas, com o hardware do sistema, com outros 
sistemas e com outros produtos. Também são descritas as restrições impostas 
pela aplicação, padrões, linguagem de implementação, ambientes operacionais e 
limites de recursos.
V. Evolução do sistema: descreve as suposições fundamentais nas quais o sistema 
se baseia e as mudanças previstas devido à evolução do hardware ou nas neces-
sidades do usuário, dentre outras.
Análise de risco: descreve os pontos de risco no projeto e as ações a serem 
contempladas para evitar ou minimizar seus impactos.
Anexo: descreve os recursos e técnicas utilizados para o levantamento de requi-
sitos, assim como as questões feitas e o nome das pessoas envolvidas.
27
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
3.1. CONCEPÇÃO
O início de um projeto de software ocorre a partir de uma nova necessidade de negócios 
identificada, de um novo mercado ou serviço ou um sistema bem defasado que não 
mais atende às necessidades e precisa ser substituído. Neste momento a comunicação 
entre todos os envolvidos e a equipe de software deve ser estabelecida para dar início 
a uma colaboração.
Como resultado será gerado um documento com a descrição geral do sistema e de 
como ele será usado dentro da organização. As fontes de informação são os gerentes 
dos departamentos em que o sistema será utilizado, os engenheiros de software fami-
liarizados com o tipo de sistema proposto, peritos em tecnologia, usuários finais, dentre 
outros conforme o tipo de aplicação.
Nesse documento são apresentados os resultados deste estudo contendo a recomen-
dação se vale a pena dar continuidade ou não no processo de engenharia de requisitos 
e no desenvolvimento do sistema. Pode também propor mudanças no enfoque, no or-
çamento e no cronograma, além de sugerir outros requisitos de alto nível. Esta tarefa se 
destina a responder a algumas perguntas:
 ` O sistema contribuirá para os objetivos gerais da organização?
 ` O sistema pode ser implementado com a utilização da tecnologia atual dentro 
das restrições de custo e prazo?
 ` O sistema pode ser integrado com outros sistemas já em operação?
 ` Como a organização se comportaria, caso o sistema não fosse implementado?
 ` Quais os problemas com os processos atuais e como um novo sistema ajudaria 
a diminuir esses problemas?
 ` Que contribuição direta o sistema trará para os objetivos da empresa?
 ` As informações podem ser transferidas para outros sistemas organizacionais ou 
recebidas a partir deles?
 ` O sistema requer tecnologia que não tenha sido usada anteriormente na organização?
 ` O que precisa e o que não precisa ser compatível com o sistema?
3.2. LEVANTAMENTO DE REQUISITOS
Nesta etapa de levantamento de requisitos os desenvolvedores trabalham com cliente 
e usuários finais para descobrir mais informações sobre o domínio da aplicação, dos 
serviços, do desempenho, das restrições de hardware etc. envolvendo assim diferentes 
tipos de pessoas. Chamamos de stakeholder qualquer pessoa com alguma influência, 
direta ou indireta, sobre os requisitos. Dentre eles estão os usuários finais, ou seja, 
todo pessoal afetado pelo sistema: desenvolvedores, mantenedores de sistemas rela-
cionados, gerente de negócios, especialistas no domínio, dentre outros. Essa tarefa de 
levantamento de requisitos contém as seguintes atividades:
28
Engenharia de Requisitos
2
 ` Compreensão do domínio da aplicação; 
 ` Coleta de requisitos: interagir com os stakeholders do sistema; 
 ` Classificação: organiza em grupos coerentes;
 ` Resolução de inconsistências e conflitos entre os stakeholders; 
 ` Definição das prioridades; e
 ` Verificação se requisitos estão completos e consistentes. 
O levantamento e a análise de requisitos são parte de um processo iterativo, com uma 
contínua validação de uma atividade para outra e, a partir daí, será gerada a Especifi-
cação de Requisitos por meio de um Documento de Requisitos.
Dificuldades encontradas 
 ` Os stakeholders muitas vezes não sabem o que querem, a não ser em termos 
muito gerais, podendo achar difícil articular o que desejam do sistema e fazer 
pedidos não realistas;
 ` Os stakeholders expressam os requisitos em seus próprios termos e com conhe-
cimento implícito de sua área de atuação e os engenheiros de requisitos devem 
entender esses requisitos;
 ` Os diferentes stakeholders têm em mente diferentes requisitos e podem expres-
sá-los de maneira distinta. Os engenheiros de requisitos devem descobrir todas 
as fontes possíveis e encontrar pontos comuns e conflitos;
 ` A falta de uma boa definição do projeto, da efetividade, de informações neces-
sárias a um perfeito diagnóstico para obter soluções inteligentes pode trazer um 
diagnóstico fraco com conclusões comprometidas e não identificação das causas 
dos problemas;
 ` O ambiente econômico e de negócios é dinâmico e se modifica durante o proces-
so de análise e assim a importância dos requisitos pode mudar e novos requisitos 
podem surgir;
 ` A escolha de técnicas adequadas para descrever os requisitos do sistema de 
modo claro, sem ambiguidades, conciso e consistente com todos os aspectos 
significativos do sistema proposto.
3.3. ELABORAÇÃO
A elaboração dos requisitos constitui-se no desenvolvimento de um modelo de requi-
sitos que identifique os diversos aspectos do funcionamento, comportamento e das 
informações que o software deve conter. 
É nessa tarefa que são criados os cenários do usuário obtidos durante o levantamento, 
mostrando como os atores vão interagir com o sistema. A partir da análise de cada 
29
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
cenário, os desenvolvedores criarão as classes e seus atributos, permitindo assim que 
os usuários visualizem os serviços que serão implementados futuramente.
3.4. NEGOCIAÇÃO
Como os usuários geralmentenão têm clareza do que precisam, pedem algo além ou 
podem também ocorrer conflitos entre as necessidades vai haver um momento para uma 
conciliação entre a equipe para a modelagem adequada dos requisitos. Torna-se neces-
sário que clientes, usuários e demais envolvidos discutam as prioridades, interajam, ava-
liem custos, riscos e conflitos internos. Dessa forma os requisitos podem ser combinados 
ou eliminados para que cada um fique satisfeito e concorde com a solução proposta.
3.5. ESPECIFICAÇÃO
Nesta fase de Especificação será gerado um documento escrito que poderá conter 
descrição de cenários de uso, modelos gráficos, um protótipo ou outros formatos que 
representem processos e funcionalidades que foram levantadas com os usuários. A 
formalidade e o formato de uma especificação variam com o tamanho e a complexidade 
do software a ser construído.
3.6. VALIDAÇÃO E REVISÃO DOS REQUISITOS
O processo de validação e revisão dos requisitos torna-se fundamental para evitarmos 
retrabalho futuro e o não atendimento correto das necessidades. Identifica-se os se-
guintes tipos de verificação:
 ` Verificação de validade: identificar funções adicionais ou diferentes;
 ` Verificação de consistência: não devem existir requisitos conflitantes, restri-
ções contraditórias ou diferentes para uma mesma função;
 ` Verificação de completude: todas as funções e restrições exigidas pelo usuário;
 ` Verificação de realismo: com conhecimento da tecnologia existente, verificar 
se os requisitos realmente podem ser implementados dentro do orçamento e 
prazos definidos;
 ` Facilidade de verificação: requisitos escritos de modo a serem verificados.
Para o processo de revisão é necessário considerar técnicas de validação que conside-
rem os aspectos formais e informais:
 ` Revisão informal: envolve os desenvolvedores e tantos stakeholders quantos 
possível para discutir os requisitos.
 ` Revisão formal: aqui a equipe de desenvolvimento deve “conduzir” o cliente, 
mostrando implicações de cada requisito. Os revisores verificam os requisitos 
considerando os aspectos de:
 � consistência e completude;
30
Engenharia de Requisitos
2
 � facilidade de verificação se pode ser testado;
 � facilidade de compreensão pelos usuários ou compradores;
 � facilidade de rastreamento, se a origem é claramente definida; e 
 � adaptabilidade, se o requisito é adaptável.
Desta forma os conflitos, contradições, erros e omissões devem ser detectados e des-
cartados durante a revisão e formalmente registrados e assim os usuários, comprado-
res e desenvolvedores devem negociar a solução para esses problemas.
3.7. GERENCIAMENTO DE REQUISITOS 
O processo de gerenciar os requisitos está em constante mudança durante o processo 
de Engenharia de Requisitos e no desenvolvimento de sistemas, visto que é comum 
surgirem novos requisitos após o sistema começar a ser usado.
É essencial manter o controle das necessidades individuais e manter as ligações entre 
os requisitos dependentes, para que possam ser avaliados os impactos das mudanças 
nos requisitos. Torna-se, portanto, necessário estabelecer um processo formal para fa-
zer propostas de mudança e ligar essas aos requisitos de sistema.
Dentre as mudanças nos requisitos as mais comuns são:
 ` O ambiente técnico e de negócios do sistema muda após a instalação;
 ` Um novo hardware pode ser introduzido; 
 ` Novas interfaces do sistema com outros sistemas; 
 ` As prioridades do negócio podem mudar;
 ` As pessoas que pagam por um sistema e os usuários desse sistema raramente 
são as mesmas pessoas;
 ` Os clientes do sistema impõem requisitos devido a restrições orçamentárias e 
organizacionais; e
 ` Pode existir conflito com os requisitos do usuário final e, após a entrega, ser ne-
cessário adicionar novos recursos para suporte ao usuário.
Planejamento do Gerenciamento
Para um bom gerenciamento torna-se necessário um planejamento e definição do nível de 
detalhamento necessário para certos processos e decisões do gerenciamento de requisitos:
 ` Identificação de requisitos: cada requisito deve ser identificado exclusivamen-
te para que ele possa ser comparado com outros requisitos;
 ` Processo de gerenciamento de mudanças: definição de um conjunto de ativi-
dades que avaliam o impacto e o custo das mudanças;
31
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
 ` Políticas de rastreabilidade: essas políticas definem as relações entre cada 
requisito e entre os requisitos e o projeto do sistema que deve ser registrado;
 ` Ferramentas de suporte: variam desde sistemas especialistas até planilhas e 
sistemas de banco de dados. 
Gerenciamento de Mudança
Em situações que envolvam mudanças nos requisitos o gestor analisa e toma decisões 
conforme as situações e para tal precisa:
 ` Decidir se uma mudança de requisitos deve ser aceita;
 ` Analisar o problema e a especificação de mudanças para verificar se é válida. O fe-
edback dessa análise é devolvido para o solicitante, que pode responder com uma 
proposta mais específica de mudança dos requisitos, ou decidir retirar o pedido;
 ` Analisar as mudanças e custos: o efeito da mudança proposta é avaliado por 
meio de informações de rastreabilidade e conhecimento geral dos requisitos do 
sistema. Uma vez que essa análise é concluída, toma-se a decisão de prosseguir 
ou não com a mudança de requisitos.
4.TÉCNICAS DE LEVANTAMENTO DE REQUISITOS
As técnicas visam superar as dificuldades desta fase e cada uma tem seu conceito 
próprio, vantagens e desvantagens e podem ser utilizadas em conjunto pelo desenvol-
vedor de sistemas visto que nenhuma técnica por si só é suficiente para projetos reais. 
A escolha das técnicas que serão utilizadas depende de vários fatores e dentre eles 
podemos considerar: 
 ` A complexidade e os objetivos do produto de software a ser desenvolvido;
 ` O conhecimento do desenvolvedor (ou engenheiro de requisitos) responsável 
pela produção dos requisitos, que vai liderar o processo e com habilidade de 
empregar um processo sistemático, que poderá ser auxiliado por outros desen-
volvedores especialistas em documentação, bem como pessoal de apoio; e
 ` Dos usuários potenciais do produto fazem parte do processo.
Cada técnica tem as suas recomendações e características, mas de uma forma geral 
todas seguem alguns procedimentos básicos:
 ` Perguntar: identificar a pessoa apropriada e perguntar;
 ` Observar e inferir: observar o comportamento dos usuários e inferir suas necessidades;
 ` Discutir e formular: discutir com os usuários suas necessidades e, juntamente 
com eles, formular um entendimento comum dos requisitos;
 ` Negociar: começar com um conjunto-padrão e negociar quais desses requisitos 
serão incluídos, excluídos ou modificados;
32
Engenharia de Requisitos
2
 ` Estudar e identificar problemas: identificar os requisitos que podem melhorar o 
produto;
 ` Supor: quando não existe usuário, ou na criação de um produto inexistente é 
preciso usar intuição.
As técnicas podem ser assim classificadas:
 ` Métodos de Conversação;
 ` Métodos de Observação;
 ` Métodos Analíticos;
 ` Métodos Sintéticos;
 ` Orientados a Ponto de Vista.
4.1. MÉTODOS DE CONVERSAÇÃO
Entende-se por conversação um meio de comunicação verbal entre duas ou mais pes-
soas. É uma forma natural de expressar as necessidades, ideias, responder às per-
guntas para identificar os requisitos do produto. Nestes métodos podemos considerar a 
entrevista, um workshop, brainstorming, questionário e grupo focal.
ENTREVISTA
Entrevista é a técnica tradicional, mais simples de utilizar, e produz bons resultados na 
fase inicial de obtenção dos dados. É caracterizada por uma série de encontros com 
os usuários onde o entrevistador deve dar espaço aos entrevistados para explicar seu 
trabalho, ambiente no qual atuam e esclarecer as suas necessidades.
Por se tratar de uma técnica estruturada, que pode ser aprendida pelos desenvolvedores 
a fim de ganhar proficiência e habilidades sociais para não apenasouvir, mas dar espaço 
ao entrevistado para esclarecer as suas necessidades e assim discutir o projeto desejado 
com diferentes grupos de pessoas. Dentre as fases da entrevista consideramos:
Planejamento da entrevista
 ` Coletar, ler e/ou estudar dados pertinentes à discussão, como documentos e 
formulários e descobrir que informação o usuário está mais interessado e assim 
estabelecer o objetivo da entrevista;
 ` Decidir quem será entrevistado, incluindo uma pessoa chave de cada nível afe-
tado e pedir ajuda na empresa para a escolha de pessoas;
 ` Obter informações sobre a frequência e a previsibilidade dos serviços com dados 
atualizados;
 ` Preparar os entrevistados, avisar a data e duração, comunicar o assunto;
33
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
 ` Preparar lista de questões direcionadas para o objetivo da entrevista e com as 
informações obtidas, serão preparadas novas questões;
 ` Desenvolver um plano para uso eficiente do tempo evitando dispersão do assunto que 
a torne longa e cansativa e certificar-se da autorização para falar com os usuários. 
Realização da entrevista
 ` Elaborar perguntas detalhadas e solicitar que o usuário:
 � Explique o relacionamento entre o que está em discussão e as demais partes do sistema;
 � Descreva o ponto de vista de outros usuários em relação ao item que esteja sendo discutido;
 � Descreva informalmente a narrativa do item em que o analista deseja obter informações;
 � Perguntar ao usuário se o item em discussão depende para a sua existência de alguma 
outra coisa, para assim poder juntar os requisitos comuns do sistema, formando assim 
um escopo conciso.
 ` Modelo pirâmide: começa com questões fechadas para obter respostas diretas 
e expandir os tópicos com questões abertas dirigidas;
 ` Modelo funil: começa questões abertas dirigidas obtendo detalhes de dá conti-
nuidade obtendo respostas diretas com questões fechadas;
 ` Modelo diamante: mescla os dois modelos e fica menos cansativa pois varia os 
tipos de questões;
 ` Utilizar ferramentas automatizadas;
 ` Usar um estilo adequado ao entrevistar;
 ` Ter a facilidade para alterar a ordem, eliminar e incluir perguntas;
 ` Determinar um escopo limitado para que a reunião não se estenda por mais de 
uma hora; 
 ` Evitar o uso excessivo de termos técnicos e não conduzir a entrevista em uma 
tentativa de persuasão;
 ` Nunca deve criticar a credibilidade do entrevistado, pois ele é o perito no assunto. 
Finalização da entrevista
 ` Validar o que foi documentado pelo analista, realizando uma checklist com o 
usuário para validar o que entendeu e verificar os tópicos que necessitam de 
informação adicional;
 ` Explicar as próximas ações a serem tomadas;
 ` Validar o que foi documentado pelo analista realizando uma checklist com o usu-
ário para validar o que entendeu;
34
Engenharia de Requisitos
2
 ` Agradecer o entrevistado pelo tempo e esforço dedicados e até enviar agradeci-
mento por escrito.
Atividades após a entrevista
 ` Descobrir ambiguidades e informação conflitante ou ausente;
 ` Produção de um resumo escrito, ordenando os tópicos discutidos, consolidando 
as informações obtidas, com oportunidade para o entrevistado revisar e corrigir 
este resumo caso necessário;
 ` Revisar procedimentos utilizados para preparar e conduzir a entrevista e melho-
rar o processo.
Habilidades e estratégias para comunicação oral
 ` A primeira resposta para a pergunta pode não estar necessariamente completa 
e correta;
 ` Pode ser expressa em uma linguagem desconhecida para o entrevistador (re-
sumir, refrasear e mostrar as implicações do que o entrevistador está ouvindo);
 ` A sumarização é útil durante a entrevista toda e não só no final pois confirma o 
entendimento, generalizações e abstrações de alto nível;
 ` Algumas questões específicas não devem induzir respostas;
 ` Perguntas com respostas do tipo “sim” ou “não” permitem que o entrevistado 
responda sem que precise de muito tempo para pensar;
 ` Uma única pergunta sobre um determinado tópico pode não produzir uma res-
posta completa ou significativa;
 ` Explorar os tópicos com questões que os abordem em diferentes níveis de abstração.
Erros mais comuns
 ` Erros de observação: pessoas diferentes se concentram em diferentes aspec-
tos e podem “ver” coisas diferentes;
 ` Erros de memória: o entrevistado pode estar confiando demais na lembrança 
de informações específicas, e a memória humana pode falhar;
 ` Erros de interpretação: o entrevistador e o entrevistado podem estar interpre-
tando palavras comuns de maneira diferente, tais como “pequena quantidade de 
dados” ou “caracteres especiais”;
 ` Erros de foco: o entrevistador pode estar pensando de maneira ampla, e o en-
trevistado pode estar pensando de maneira restrita (ou vice-versa), o que afeta o 
nível de abstração na discussão daquele tópico;
35
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
 ` Ambiguidades: há ambiguidades inerentes á maioria das formas de comunica-
ção, especialmente a língua natural;
 ` Conflitos: entrevistador e entrevistado podem ter opiniões conflitantes sobre um 
determinado problema, e a tendência é registrar o ponto de vista do entrevista-
dor;
 ` Fatos que simplesmente não são verdadeiros: o entrevistado pode dar infor-
mações que ele assume como fatos verdadeiros, mas que, na verdade, são só 
a sua opinião.
WORKSHOP
O workshop é uma técnica de elicitação em grupo usada em uma reunião estruturada 
em que fazem uma equipe de analistas, uma seleção dos stakeholders que melhor re-
presentam a organização e o contexto em que o sistema será usado.
 ` Obter um conjunto de requisitos bem definido;
 ` Há um facilitador neutro cujo papel é conduzir a workshop e promover a discus-
são entre os vários mediadores;
 ` A convocação deve possuir dia, hora, local, horário de início e de término; assun-
to a ser discutido e a documentação;
 ` As tomadas de decisão são baseadas em negociações mediado pelo facilitador;
 ` Produzir documentações que refletem os requisitos e decisões tomadas sobre 
o sistema; 
 ` Trabalho em equipe torna o levantamento de requisitos mais eficaz e com baixo custo;
 ` Tempo de obtenção de informações é reduzido.
BRAINSTORMING
É uma técnica básica para geração de ideias. Em uma ou várias reuniões é apresen-
tado o problema/necessidade a um grupo específico, requerendo assim soluções. As 
pessoas sugerem e exploram ideias sem que sejam criticadas ou julgadas. Pensando 
nisso, deve ser gerada uma documentação que reflete os requisitos e as decisões to-
madas sobre o sistema.
Etapas para conduzir uma sessão de brainstorming
 ` Seleção dos participantes: para contribuições diretas, pessoas bem informadas, 
de diferentes grupos garantindo uma boa representação;
 ` O líder da sessão explica os conceitos básicos e as regras a serem seguidas 
durante a sessão;
 ` Os participantes expõem suas ideias, um por vez e, se alguém tiver problema, 
passa a vez e espera a próxima rodada, produzindo assim uma boa quantidade 
36
Engenharia de Requisitos
2
de ideias, pois quanto mais ideias forem propostas, maior será a chance de apa-
recerem boas ideias; 
 ` É útil na geração de várias visões do problema e na sua formulação de diferentes 
maneiras;
 ` Ideias que pareçam não convencionais são encorajadas, pois elas frequente-
mente estimulam os participantes, o que pode levar a soluções criativas para o 
problema, ou mesmo combinas uma ou mais ideias; 
 ` Uma pessoa registra todas as ideias e estas ficam visíveis a todos;
 ` Analisar e consolidar as ideias que são discutidas, revisadas, organizadas e avaliadas;
 ` revisão das ideias e as consideradas valiosas pelo grupo são mantidas e classi-
ficadas em ordem de prioridade;
 ` São identificados os requisitos absolutamente essenciais, os bons mas não es-
senciais e os apropriados para uma versão subsequente do software.
QUESTIONÁRIO
O questionário é uma forma rápida de se obter dados quandohá muitos usuários para 
extrair as mesmas informações e quando eles podem estar em diversos locais diferen-
tes e há dificuldade em estar em todos esses locais. Para organizar melhor as entrevis-
tas, quando se deseja conhecer o sistema, podem ser coletados vários tipos de dados, 
incluindo a utilização do sistema atual, problemas que os usuários enfrentam em seu 
trabalho e expectativas em relação ao novo sistema.
Como estruturar o processo
Há várias categorias de problemas que podem ajudar o analista a estruturar o processo 
de elaboração do questionário, dentre eles: desempenho (ou performance), informação 
e dados, economia, controle, eficiência e serviços. Dessa forma, o analista deve:
 ` Eaborar questões autoaplicáveis e dirigidas por escrito aos participantes para ter 
conhecimento sobre opiniões; 
 ` Elaborar questões de forma simples e clara pois uma forma padronizada garante 
uniformidade;
 ` Desenvolver de forma a minimizar o tempo gasto nas respostas e assim utilizar 
resposta múltipla escolha, lista de verificação ou questões abertas;
 ` Preparar o questionário com um título e tipo de informação que se deseja obter; 
 ` Agrupar as questões de tópicos específicos; 
 ` Desenvolver um controle que identifique todas as pessoas que receberão os 
questionários; 
37
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
 ` Permitir que os participantes respondam quando acharem conveniente;
 ` Distribuir e oferecer instruções sobre o preenchimento indicando prazo de devo-
lução;
 ` Analisar as respostas e elaborar consolidação das informações fornecidas; 
 ` Ajuda a lidar com dificuldades de articulação dos problemas e comunicação;
 ` Auxiliar na análise de produtos já existentes (manuais ou automatizados);
 ` Coletar informações se os usuários tendem a não utilizar o possuem sintomas de 
que informações estão erradas ou de forma diferente do que necessitam;
 ` Analisar o desempenho do sistema em relação a tempo de resposta, demanda 
em momentos de pico, entre outros fatores que permitam um entendimento a 
carga esperada e do nível de serviço necessário ao produto; 
 ` Levantar necessidade de algum tipo de controle para alguns produtos com por 
exemplo o acesso restrito a certos usuários ou a certas horas do dia ou tipo de 
acesso restrito para somente leitura ou leitura e escrita.
GRUPO FOCAL (FOCUS GROUP)
Nesta técnica são criados grupos de discussão informal e de tamanho reduzido, poden-
do ser de até 12 pessoas para obter informação em profundidade sobre determinado 
assunto ou processo. Dentre as características podemos considerar:
 ` Convidar as pessoas para participar da discussão sobre determinado assunto 
específico;
 ` Obter informações qualitativas a curto prazo, baixo custo e com flexibilidade;
 ` Esclarecer questões complexas no desenvolvimento de projetos;
 ` Ter um facilitador/moderador com experiência para conduzir o grupo;
 ` Realizar seleção criteriosa dos participantes.
4.2. MÉTODOS DE OBSERVAÇÃO
Os métodos de levantamento de requisitos nesta categoria de observação são utiliza-
dos para a compreensão do domínio da aplicação, observando as atividades humanas. 
Dentre eles podemos destacar a etnografia, a observação e também a existência do 
protocolo de análise.
ETNOGRAFIA
Com a técnica de etnografia podemos compreender os requisitos humanos, sociais e 
organizacionais desempenhados em uma dada organização e assim utilizá-la quando 
necessitamos um entendimento completo, detalhado e com maior profundidade. Nesta 
38
Engenharia de Requisitos
2
observação podemos entender a política organizacional e a cultura de trabalho familiari-
zando-se com o sistema e sua história. Ao mesmo tempo, precisamos ficar atentos, pois 
essa técnica pode causar um certo desconforto nas pessoas que estão sendo observa-
das e pode consumir mais tempo que outras técnicas. Por esee motivo, é utilizada como 
complementar. Dentre alguns aspectos para a utilização desta técnica recomenda-se:
 ` Observar o trabalho diário e anotar as tarefas reais em que o sistema será utili-
zado;
 ` Descobrir requisitos de sistema implícitos da maneira como as pessoas realmen-
te trabalham; 
 ` Descobrir requisitos derivados da cooperação e conscientização das atividades 
de outras pessoas;
 ` Antes de iniciar a observação, identificar as áreas de usuário a serem observa-
das; obter a aprovação das gerências, nomes e funções das pessoas chave e 
explicar a finalidade do estudo;
 ` Familiarizar-se com o local de trabalho, observar os agrupamentos, as facilida-
des manuais e automatizadas;
 ` Coletar amostras de documentos e procedimentos escritos;
 ` Acumular informações estatísticas a respeito das tarefas, como: frequência que 
ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está 
sendo observada;
 ` Observar as operações normais de negócios e as exceções;
 ` Documentar as descobertas resultantes das observações feitas;
 ` Consolidar o resultado revendo os resultados com as pessoas observadas e/ou 
com seus superiores;
OBSERVAÇÃO 
A técnica de observação pura, e simplesmente sem entrar no aspecto da etnografia, é 
quando simplesmente visitamos o local a ser observado para obter informações sobre os 
processos diários que são desenvolvidos baseando-se apenas no cotidiano das operações. 
O objetivo é captar o comportamento natural das pessoas, causar um nível de intromissão 
relativamente baixo e assim observar de forma confiável com baixo nível de inferência.
ANÁLISE DE PROTOCOLO
Análise de protocolo é uma forma de levantamento de requisitos no qual o analista 
examina as partes interessadas quando estão envolvidas em algum tipo de tarefa. Para 
esse dever, o analista precisa ter conhecimento suficiente sobre domínio atual, a fim de 
compreender melhor as tarefas. Lembrando que esse processo de extração de registro 
de tarefas via áudio ou vídeo muitas vezes exige a autorização formal e registrada pelas 
pessoas envolvidas.
39
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
4.3. MÉTODOS ANALÍTICOS
Os métodos analíticos consistem em um conjunto de técnicas para análise de documen-
tação e conhecimento existentes. Por meio deles são adquiridos requisitos como domínio 
do negócio, fluxos de trabalho e características do produto com maior volume de detalhes.
Utiliza-se essas técnicas quando se requer dados empíricos, do cotidiano, documenta-
ção e opinião de especialistas, pois sem estes, não é possível identificar os requisitos. 
Assim, por meio de um estudo feito por especialistas no assunto garante-se maior co-
nhecimento e aumenta a maturidade e qualidade dos dados levantados. Lembrando 
que, se possível, reutilizar informação já disponível salva tempo e custo. 
REUSO DE REQUISITOS
O estudo e a reutilização de especificações e glossários referentes a projetos de siste-
mas legados ou a sistemas de mesma família com funcionalidades de negócio similares 
economizam tempo e recursos. 
Pode-se levar também a uma reutilização de itens em outras atividades do ciclo de vida 
de desenvolvimento, como por exemplo o design de componentes já existentes, testes 
e código fonte. 
Há também como benefício a redução de risco, pois requerimentos reutilizados têm 
uma chance maior de serem compreendidos pelos stakeholders visto que já são conhe-
cidos de certa forma.
ESTUDO DE DOCUMENTAÇÃO/ANÁLISE DE CONTEÚDO
É muito comum utilizar e estudar a documentação existente, sejam elas de diferentes 
naturezas, para a identificação de requisitos a serem implementados no sistema que se 
está modelando.
Dentre a variedade de documentação que pode ser analisada podemos identificar a 
estrutura organizacional da empresa, padrões de mercado, leis, manuais de usuário, 
relatórios de pesquisas de mercado, glossário de termos de negócio, dentre outros. O 
cuidado em ficar atento a documentos desatualizados e com problemas que podem 
levar a uma falha na definição dos requisitos é também importantíssimo para o estudo.
LADDERINGTrata-se de um método de entrevistas estruturadas, um a um, utilizado para o levanta-
mento de conhecimento de especialistas, visando saber o que é importante e por quê. 
Uma estratégia para isso é criar, revisar e modificar a hierarquia de conhecimento dos 
especialistas, em geral na forma de diagramas hierárquicos pois assim pode cobrir um 
amplo domínio de requisitos.
Essa técnica necessita de menos experiência para a execução das sessões de levanta-
mento e provê um formato padrão, às vezes até automatizado e que é combinado com 
outras técnicas, tornando-se assim uma técnica complementar.
40
Engenharia de Requisitos
2
SORTEIO DE CARTÕES
Se tivermos muitos usuários que são especialistas no domínio do assunto e queremos a par-
ticipação de todos, podemos utilizá-los para capturar informações e ideias sobre estruturas de 
requisitos, utilizando um conjunto de cartões distribuídos em um grupo de stakeholders. Cada 
cartão é impresso com a descrição das entidades do domínio e, assim que são sorteados 
entre os participantes, esses cartões ajudarão os stakeholders a levantar os conceitos do do-
mínio e distinguir entre os problemas de alto e baixo nível. Todos participam do processo e o 
resultado pode ser utilizado como insumo para outros métodos de levantamento de requisitos.
REPERTORY GRID
Nesse método, o objetivo é ter subsídios para a modelagem de dados que será realizada pos-
teriormente. Os stakeholders são questionados sobre os atributos e valores referentes a uma 
série de entidades e, com essa informação, é montada uma matriz de entidade X atributo.
4.4. MÉTODOS SINTÉTICOS
Chamamos de métodos sintéticos, pois são formados pela combinação das várias téc-
nicas em uma única. Dentre eles podemos citar as sessões de JAD e a prototipação. 
SESSÕES JOINT APPLICATION DESIGN (JAD)
O conceito do JAD de abordagem e dinâmica de grupo pode ser utilizado para diversas 
finalidades, como: planejamento de atividades técnicas para um grande projeto, discus-
são do escopo e objetivos de um projeto e estimativa da quantidade de horas necessá-
rias para desenvolver sistemas grandes e complexos.
É composto de workshops e sessões de grupo nos quais stakeholders e desenvolve-
dores se encontram para discutir as características desejadas do produto. Dentre os 
objetivos e aspectos importantes podemos destacar:
 ` Envolver todos os stakeholders importantes no processo de levantamento, atra-
vés de reuniões estruturadas e com foco bem definido;
 ` Promover cooperação, entendimento e trabalho em grupo entre os usuários e 
desenvolvedores;
 ` Facilitar a criação de uma visão compartilhada do que o produto de software 
deve ser; e
 ` Ajudar desenvolvedores e usuários a formularem problemas, explorar soluções e 
assim ganharem um sentimento de envolvimento, posse e responsabilidade com 
o sucesso do produto.
Princípios básicos do JAD
 ` Dinâmica de grupo, em que há reuniões com um líder experiente, analista, usu-
ários e gerentes, para despertar a força e criatividade dos participantes, para 
determinar os objetivos e requisitos do sistema;
41
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
 ` Uso de técnicas visuais, para aumentar a comunicação e o entendimento;
 ` Manutenção do processo organizado e racional, em que a análise top down e as 
atividades bem definidas. A garantia de uma análise completa reduz as chances 
de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção; e
 ` Utilização de documentação padrão, preenchida e assinada por todos os parti-
cipantes, garantindo qualidade esperada do projeto e promovendo a confiança 
dos participantes.
A técnica JAD é composta de duas etapas principais: planejamento e projeto. Pla-
nejamento, que se refere à etapa de licitação e à especificação dos requisitos. Projeto, 
por sua vez, é o gerenciamento e o desenvolvimento do sistema. Cada etapa possui 
três fases: 
 ` Preparação: escolha dos participantes, garantia de agenda, acordo para os par-
ticipantes e preparo do material;
 ` Sessão: realização dos encontros estruturados, envolvendo desenvolvedores e 
usuários onde os requisitos são desenvolvidos e documentados; 
 ` Revisão: rever a documentação produzida na sessão e examinar melhorias na 
sistemática adotada.
Tipos de Participantes (nem todos participam de todas as fases).
 ` Patrocinador (cliente): estabelece as diretrizes e objetivos do projeto. Possui 
autoridade formal sobre as áreas de negócios afetadas pelo desenvolvimento do 
produto. É ele quem faz a abertura da primeira sessão, apresenta os participan-
tes envolvidos;
 ` Usuários chaves: são aqueles que utilizarão o sistema e são responsáveis pelo 
conteúdo da sessão, provendo informações de negócios e compartilhando suas 
necessidades e como o novo produto poderia resolver os problemas por eles 
reportados;
 ` Engenheiro de sistemas (analista de requisitos): responsável por criar os do-
cumentos das sessões JAD contendo o registro das decisões e especificações 
produzidas. Deve possuir a habilidade para compreender as questões técnicas e 
os detalhes discutidos em uma sessão;
 ` Executor (Analista de sistemas): responsável pelo desenvolvimento do pro-
duto, fornecendo aos participantes uma visão geral do produto e aloca recursos.
 ` Condutor (líder de sessão): pessoa que irá conduzir a JAD e reunir o pessoal 
para as sessões. Recomenda-se que o facilitador de encontros possua qualida-
des gerenciais de liderança e bom relacionamento interpessoal;
 ` Observadores (eventuais participantes): outras pessoas interessadas no pro-
jeto que não são participantes e não opinam durante as sessões.
42
Engenharia de Requisitos
2
PROTOTIPAÇÃO
A técnica de prototipação nessa etapa de levantamento de requisitos ajuda os stakehol-
ders a desenvolver uma forte noção sobre a aplicação, ainda não implementada. Com 
a visualização do protótipo, podem identificar os reais requisitos e fluxos de trabalho do 
sistema. Dentre alguns aspectos importantes da prototipação identificamos que: 
 ` Utilizada quando os stakeholders não conseguem expressar seus requisitos ou 
se não têm nenhuma experiência com o sistema;
 ` Utilizada no estágio inicial do projeto; 
 ` Implementa de forma rápida um pequeno subconjunto de funcionalidades do 
produto;
 ` Indicada para estudar as alternativas de interface de entrada ou de saída e even-
tuais problemas de comunicação com outros produtos;
 ` Reduz riscos na construção do sistema, pois o usuário chave já verifica o que o 
analista captou nos requisitos do produto; 
 ` Escolhe ferramenta e/ou ambiente de prototipação;
 ` Permite alcançar um feedback antecipado dos stakeholders; 
 ` Reduz tempo e custo de desenvolvimento com a detecção de erros em uma fase 
inicial do projeto; 
 ` Prove maior nível de satisfação dos usuários devido a sensação de segurança 
ao ver algo próximo do real;
 ` Demanda maior custo de investimento, em relação a outros métodos, para ser rea-
lizado pois pode demandar ferramentas automatizadas para geração de protótipos; 
 ` Demanda maior tempo maior para sua realização devido à complexidade do 
sistema e a limitações técnicas.
4.5. DEFINIÇÃO DE REQUISITOS ORIENTADA A PONTO DE VISTA 
Essa técnica denominada VORD (Viewpoint-oriented Requirements Definition) oferece 
um framework orientado a serviço para o levantamento e análise de requisitos visando 
descobrir conflitos nos requisitos propostos por diferentes tipos de usuários. Esses usuários 
reconhecem a existência de várias perspectivas e enxergam o problema de modo diferente.
Um receptor de serviços externos ao sistema e que dele recebem serviços pode forne-
cer dados ou sinais de controle e assim examinar os serviços recebidos por diferentes 
pontos de vista.
Os pontos de vista e os serviços são um meio útil de estruturar os requisitos não fun-
cionais. Cada serviço pode ter requisitos não funcionais associados. Os pontos de vista 
permitem que o mesmo serviço tenha diferentes requisitos não funcionais.
432
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
Etapas da análise de ponto de vista 
 ` Identificação dos pontos de vista: descobrir os pontos de vista que utilizam 
quais serviços específicos. Utilizar o brainstorming para identificar os serviços 
em potencial e as entidades que interagem com o sistema;
 ` Estruturação de pontos de vista: agrupar pontos de vista relacionados, segun-
do uma hierarquia. Serviços comuns estão localizados nos níveis mais altos da 
hierarquia e herdados por pontos de vista de nível inferior;
 ` Documentação do ponto de vista: refinar a descrição dos pontos de vista e 
serviços identificados;
 ` Mapeamento de sistema: conforme ponto de vista envolve identificar objetos uti-
lizando as informações de serviço que estão encapsuladas nos pontos de vista.
CONCLUSÃO
Mudanças nos requisitos acontecem na maioria dos sistemas complexos, embora mui-
tas delas sejam devido a mudanças das necessidades dos usuários, enquanto outras 
mudanças advêm da interpretação incorreta dos requisitos do produto a ser desenvol-
vido. Deve-se também considerar que requisitos incompletos, incorretos ou mal-enten-
didos são as causas mais frequentes da baixa qualidade, além do aumento dos custos 
previstos e do atraso na entrega do produto de software.
Todos os métodos de levantamento de requisitos possuem vantagens e desvantagens a 
serem consideradas. Afinal, nenhum deles é completo dadas as inúmeras variáveis de 
complexidade, perfil de stakeholders, comunicação, nível de conhecimento do negócio, 
nível de qualificação dos profissionais de levantamento de requisitos, situações políti-
cas, nível de comprometimento dos stakeholders etc. 
Com isso, a utilização de mais de uma técnica, de forma combinada, ou a utilização de 
técnicas sintéticas, irá ajudar na complementação de possíveis lacunas de levantamen-
to, além de melhorar a qualidade e completude dos requisitos, visto que pode ocorrer o 
batimento cruzado de requisitos similares. Outro fator importante é a utilização de um 
framework de decisão para a escolha dos métodos mais apropriados dado o contexto 
do trabalho a ser realizado.
Não existe uma técnica padrão para o processo de levantamento de requisitos. Para 
alcançar um levantamento de requisitos mais preciso é importante o conhecimento de 
diversas técnicas para saber qual técnica de levantamento deverá ser aplicada em cada 
situação.
É primordial que o desenvolvedor de sistemas possua perfil adequado, mais do que 
apenas a capacidade de desenhar fluxogramas e outros diagramas técnicos. Deve pro-
jetar e analisar sistemas de ótimo desempenho e tenha a capacidade de:
 ` Compreender conceitos abstratos, reorganizá-los em divisões lógicas e sinteti-
zar soluções baseadas em cada divisão;
44
Engenharia de Requisitos
2
 ` Absorver fatos pertinentes de fontes conflitantes ou confusas;
 ` Entender os ambientes do usuário/cliente;
 ` Aplicar elementos do sistema de hardware e/ou software aos elementos do usu-
ário/cliente; e
 ` Comunicar-se bem nas formas escrita e verbal e entender o objetivo global do 
software.
45
2
Engenharia de software
U
ni
ve
rs
id
ad
e 
S
ão
 F
ra
nc
is
co
REFERÊNCIAS BIBLIOGRÁFICAS
LAUDON, Kenneth C.; LAUDON, Jane P. Sistemas de Informação Gerenciais: Administrando a Empre-
sa Digital. São Paulo: Grupo A, 2023. E-book. Disponível em: https://integrada.minhabiblioteca.com.br/#/
books/9788582606032/. Acesso em: 28 jan. 2023. 
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. São Paulo: Grupo A, 2021. E-book. 
Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 29 jan. 2023.
	_Hlk125910481
	_Hlk126101390