II_Teorico

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Engenharia de 
Requisitos
Tipos de Requisitos e sua Elicitação
Responsável pelo Conteúdo:
Prof. Me. Afonso Maria Luiz Rodrigues Pavão
Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
Nesta unidade, trabalharemos os seguintes tópicos:
• Tipos de Requisitos e sua Elicitação.
Fonte: iStock/Getty Im
ages
Objetivos
• Descrever métodos para a identificação e a determinação dos tipos de requisitos de 
software a serem explorados pelo processo de software.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Tipos de Requisitos e sua Elicitação
UNIDADE 
Tipos de Requisitos e sua Elicitação
Contextualização
O processo de desenvolvimento de software por si só exige grande atenção e res-
ponsabilidade dos engenheiros e arquitetos, pois envolve diversas técnicas e conceitos, 
alguns bastante genéricos e outros muito específicos.
Além disso, as necessidades dos usuários (e suas diversas especializações) 
são distintas, o que dificulta mais o trabalho do desenvolvedor. Obviamente, não 
podemos nem pensar que um desenvolvedor irá conhecer todos os processos em 
detalhes em sua empresa e, menos ainda, qualquer processo que requeira seu 
trabalho. Ainda que sua experiência seja alta, isso não é possível.
É claro que seu conhecimento anterior sempre irá colaborar caso se envolva em um 
novo projeto, mas sempre será necessário conhecer o processo novo para se 
pensar em desenvolver um novo projeto.
Quanto aos usuários, estes podem ter vasto conhecimento e experiência nos 
processos em que são especialistas. Podem inclusive ter participado por experi-
ências em desenvolvimento de projeto de software – e mais – na mesma empresa 
onde atuam e com os mesmos profissionais desenvolvedores. Mas, isso não é 
sinônimo nem garantia de que terá sucesso em um novo projeto.
Isso acontece principalmente devido ao fato de que no momento o cenário 
e os objetivos organizacionais – e até mesmo das equipes de trabalho ou desen-
volvedores - também são mutáveis, assim como seu desempenho, empenho, 
motivação e determinação.
Igualmente, não se pode pensar que a tecnologia já utilizada com sucesso também 
seja garantia de bons resultados. Pode ser um sinalizador, não uma garantia de fato. 
E é exatamente essa tecnologia que acaba interferindo diretamente nos an-
seios da comunidade usuária, não só porque seu perfil já passou por grandes 
mudanças, como também, porque seu envolvimento com a tecnologia aumentou 
drasticamente, assim como suas exigências com relação a ela.
As técnicas existentes para se especificar os requisitos de um software aumen-
tam a chance de sucesso em um projeto de desenvolvimento, pois têm como ob-
jetivo facilitar o trabalho dos envolvidos em um projeto de software, minimizando 
os efeitos das diferenças de perfil, experiência ou envolvimento das partes.
Estas também contribuem para reduzir os custos do desenvolvimento do projeto de 
um software e também para evitar custos adicionais na correção de erros ou falhas na 
execução do software, decorrentes de enganos no início da fase de seu projeto.
Para isso, nesta unidade, vamos conhecer e explorar os diversos tipos de requisitos e 
as técnicas para sua obtenção.
6
7
Tipos de Requisitos e sua Elicitação
A engenharia de requisitos se destaca pelas técnicas de fazer uma coleta de dados 
visando conhecer as necessidades dos usuários e pelas atividades relacionadas com sua 
especificação e gestão.
Como está relacionada com a definição do que o sistema deverá fazer e suas 
propriedades essenciais e desejáveis, as restrições para a sua operação e também com 
o processo de desenvolvimento do software podem até ser confundidas como sendo um 
processo de comunicação. Mas isso é apenas a base para a coleta de dados.
Acima de tudo, antes de se iniciar a coleta de dados, devemos nos preocupar em 
entender a terminologia utilizada e em qual contexto ela será aplicada. Somente assim 
será possível compreendermos a extensão e a amplitude desta unidade.
Um dos aspectos requeridos para a compreensão dos requisitos é podermos avaliar 
sua amplitude, aplicabilidade, características e tipos.
Sommerville (2011) afirma que requisitos de sistema são descrições do que o sistema 
irá fazer, quais serviços serão oferecidos a seus usuários e qual será seu funcionamento. 
Desta forma, o autor define que requisitos de sistema é um conjunto de necessidades 
que devem ser atendidas.
Essas descrições refletem as necessidades dos clientes em resolver um determinado 
problema ou facilitar a aplicação de soluções já estudadas e conhecidas. 
O autor divide os requisitos em dois. Um deles são os requisitos de usuários e os iden-
tifica como sendo declarações feitas com diagramas relativos a quais serviços são espera-
dos pelo sistema e quais são as restrições para a sua operação. Entende-se, assim, que 
os requisitos de usuários são mais abstratos e genéricos. Seus principais usuários são os 
gerentes dos clientes ou dos fornecedores, os usuários finais de sistemas, os engenheiros 
dos clientes e os arquitetos de sistemas.
Os outros são os requisitos de sistemas que contêm definições detalhadas das 
funções, serviços, suas restrições operacionais e estão direcionados aos usuários finais de 
sistemas, aos engenheiros dos clientes ou aos arquitetos de sistemas ou desenvolvedores 
de software.
Esta separação, proposta pelo autor, objetiva tentar facilitar o entendimento de qual 
especificação é mais aplicável a um software ou a uma de suas rotinas. Em outras pa-
lavras, os diferentes níveis de especificação de um sistema contribuem para que seja 
fornecido o máximo de informações sobre o sistema e sob as diferentes óticas de leitores 
e usuários.
Conceitua-se, por fim, que os requisitos de um software referem-se a uma caracte-
rística do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir 
seus objetivos.
7
UNIDADE 
Tipos de Requisitos e sua Elicitação
Pressman (2011) salienta que é a engenharia de requisitos a responsável por fornecer 
mecanismos que visem ao entendimento do que o cliente de fato necessita, pois além de 
analisar suas necessidades, avalia a viabilidade de sua aplicação, dentre outras tarefas. 
Zultner (1992) apud Pressman (2011), em seu texto sobre quality function 
deployment – QFD (técnica de gestão de qualidade que transforma as necessidades do 
cliente em requisitos técnicos do software), cita a existência de três tipos de requisitos: 
os normais, os esperados e os fascinantes.
Para ele, os normais refletem objetivos e metas determinados para um produto durante 
as reuniões com o cliente. Se estiverem presentes no software o cliente ficará satisfeito.
Os esperados são aqueles considerados implícitos no produto – são tão fundamentais 
e óbvios que o cliente nem os cita. Porém, caso não estejam presentes no produto, a 
insatisfação do cliente será enorme.
Já os requisitos fascinantes são aqueles que trazem consigo outras facilidades que 
sequer haviam sido pensadas e, portanto, não são esperadas.
ConformePleeger (2004), há 3 categorias de requisitos: aqueles que devem ser total-
mente satisfeitos, os que são altamente desejáveis - mas não necessários e aqueles que 
são possíveis, mas que poderiam ser eliminados.
Mas Sommerville (2011), assim como Pressman (2011), ainda os classifica como 
sendo funcionais ou não funcionais. Aquele ainda acrescenta os requisitos de domínio.
Requisitos funcionais são aqueles diretamente ligados às funcionalidades do software 
e descrevem o que o software deve executar. Estes se preocupam com as funções e os 
serviços do sistema, ou seja, o que o sistema deve fornecer para o cliente e como irá se 
comportar em determinadas situações.
Eles descrevem uma interação entre o sistema e o ambiente, como o sistema deve 
funcionar conforme determinada situação, declara quais serviços o sistema deve forne-
cer, como deve reagir a entradas específicas e como deve se comportar em alguns casos. 
Descrevem, assim, as interações entre o sistema e seu ambiente.
Estes requisitos funcionais podem ainda ser evidentes, caso efetuados com 
o conhecimento do usuário, ou serem ocultos, se efetuados pelo sistema sem o 
conhecimento explícito do usuário.
Se o processo de produção de software depende da definição clara de qual produto 
será construído, a identificação dos requisitos funcionais é de extrema importância para 
essa produção com qualidade.
Entretanto, quando se fala em requisitos, não podemos deixar de explicar que são os 
requisitos não funcionais aqueles que acabam por trazer muitas dúvidas aos desenvolvedores.
Aliás, a clara definição sobre requisitos de software ainda não está adequadamente 
assimilada entre os autores, principalmente, quando o cenário apresentado pode trazer 
ainda mais dúvidas.
8
9
Mas se analisarmos friamente e pontualmente, veremos que requisitos não funcio-
nais, em vez de informar o que o sistema fará, colocam restrições sobre os serviços ou 
funções oferecidas pelo sistema, tais como restrições de timing sobre o processo de 
desenvolvimento, sobre padrões, dentre outras, e limitam nossas opções para criar uma 
solução para o problema. Estão vinculados à ISO - The International Organization for 
Standardizatized e à IEC - The International Electrotechnical Commition.
Temos, então, a separação dos requisitos não funcionais em nove tipos distintos: 
ambiente físico, interfaces, dados, usuários e fatores humanos, funcionalidade, 
documentação, recursos, segurança e garantia de qualidade.
Os requisitos não funcionais carregam consigo, ainda, as características da ISO/IEC 
9126 quanto a funcionalidade, usabilidade, confiabilidade, eficiência, manutenibilidade 
e portabilidade.
Os requisitos não funcionais podem afetar a estrutura do sistema, assim como, pode 
gerar inúmeros outros requisitos funcionais, como é o caso de um requisito de proteção 
que definirá, por exemplo, os serviços necessários ao sistema (SOMMERVILLE, 2011).
São esses requisitos que expressam as condições que o software deve atender 
ou as qualidades específicas que este deve ter, como por exemplo, propriedades, 
comportamento, restrição etc.
Impõem restrições no sistema, como tempo, espaço, linguagens de programação, versões 
do compilador, SGBD, sistema operacional, método de desenvolvimento, dentre outras.
A tabela 1 demonstra as propriedades esperadas pelo software e algumas das formas 
de sua medição. A obtenção dos valores relativos a cada uma delas depende de cada 
instalação e de seus mecanismos de controle e gerenciamento de hardware.
Tabela 1 – Requisitos Não Funcionais
Propriedade Métrica
Confiabilidade Tempo médio de ocorrência de falhas. 
Probabilidade de indisponibilidade por falha. 
Taxa de ocorrência de falhas. 
Disponibilidade.
Facilidade de uso Tempo requerido para treinamento. 
Número de telas para ajuda.
Manutenibilidade Número de alterações realizadas por período. 
Número de retrabalho em modificações.
Portabilidade Porcentagem de declarações dependentes do sistema-alvo. 
Número de sistemas-alvo.
Robustez Tempo de reinício após falha. 
Porcentagem de eventos geradores de falhas. 
Probabilidade de dados se corromperem devido a falhas.
Tamanho Kbytes. 
Número de chips de RAM.
Velocidade Número de transações processadas por segundo. 
Tempo de resposta ao usuário. 
Tempo para atualização de tela.
Fonte: Sommerville, 2011
9
UNIDADE 
Tipos de Requisitos e sua Elicitação
Sommerville (2011), ainda, classifica os requisitos não funcionais em requisitos do 
produto final, organizacionais e externos.
Entende que os requisitos de produto final estão relacionados em como o produto de 
software deverá se comportar. Ou seja, qual será sua eficiência quanto a desempenho ou 
espaço, confiabilidade, facilidade de uso e portabilidade.
Com relação aos requisitos organizacionais, estes estão vinculados à consequência de 
políticas e procedimentos organizacionais que devem ser seguidos, tais como entrega, 
padrões ou implementação.
Já os requisitos externos referem-se a fatores externos ao sistema e ao processo de 
desenvolvimento, como, por exemplo, a legislação, privacidade, segurança, princípios 
éticos e interoperabilidade.
Requisitos Não Funcionais
Requisitos Organizacionais Requisitos ExternosRequisitos do Produto
Requisitos de 
E�ciência
Requisitos de 
Facilidade de Uso
Requisitos de 
Entrega
Requisitos de 
Implementação
Requisitos de 
Padrões
Requisitos
Legais
Requisitos de
Privacidade
Requisitos de
Segurança
Requisitos de
Desempenho
Requisitos de
Espaço
Requisitos de
Con�abilidade
Requisitos de
Portabilidade
Requisitos de
Interoperabilidade
Requisitos Éticos
Figura 1 – Requisitos Não Funcionais
Fonte: Sommerville, 2011
As informações dos usuários demonstram, genericamente, quais podem ser as restri-
ções de um software. Entretanto, pode ser necessário seu detalhamento e classificação.
Uma das formas para essa classificação é conhecida como FURPS+, um acrônimo 
de Functionality, Usability, Reliability, Performance e Supportability. O Plus (+) se 
refere a outras circunstâncias, como design, implementação, interface, aspectos físicos, 
dentre outros.
Detalhando um pouco mais: a functionality (funcionalidade) envolve o aspecto fun-
cional do sistema a desenvolver, enquanto que a usability (usabilidade) está relacionada 
com o tempo requerido para treinar um usuário e este ser produtivo. Mas, também, 
refere-se ao tempo de duração desejado para uma operação do sistema, ajuda on-line, 
documentação do usuário ou material de treinamento.
A reliability (confiabilidade) trata-se da disponibilidade, do tempo decorrido para 
uma correção. É o máximo de tempo admitido para uma indisponibilidade no caso de 
ocorrência de uma falha. Refere-se, ainda, a precisão, ao número máximo de defeitos, 
ou, ainda, categorias de bugs, que devem preferencialmente ser categorizados por nível 
de impacto que podem causar, caso ocorram.
10
11
A categoria performance (desempenho) refere-se ao tempo de resposta requerido 
para uma transação, em segundos (o troughput). Pode ser também a medição de tran-
sações por segundo ou a capacidade das transações concorrentes, uma operação parcial 
(exceção) ou, ainda, o uso de recursos como memória, espaço em disco ou comunica-
ção, dentre outros.
A supportability (suportabilidade) que indica os padrões de uma codificação, a con-
venção de sua nomenclatura, as bibliotecas de classes ou os utilitários de manutenção.
O plus (+) se refere a outras circunstâncias, como design, implementação, interface 
ou aspectos físicos, dentre outros.
Os requisitos não funcionais ainda podem ser obrigatórios - caso necessitem existir de 
fato ou desejáveis - caso possam estar presentes na aplicação.
Podem, também, ser permanentes, quando são relativamente estáveis ou derivam-se 
da atividade central da organização e se relacionam diretamente ao domínio do sistema. 
Estes ainda podem ser transitórios ou, conforme Sommerville (2011), voláteis.
Consideram-se voláteis aqueles que provavelmente irão mudar durante o processode 
desenvolvimento do sistema ou depois que o sistema estiver em operação.
Os requisitos não funcionais são tão importantes quanto os requisitos funcionais. Estes 
restringem as possíveis soluções dos engenheiros de software e ajudam na determinação 
da qualidade do software.
Outro tipo de requisito que existe é o de domínio.
Esses são requisitos derivados do domínio da aplicação do sistema e descrevem as 
características do sistema e qualidades que refletem o domínio. Podem ser requisitos 
funcionais novos, restrições sobre requisitos existentes ou, ainda, computações específi-
cas ou especificidades computacionais de um algoritmo ou do processo em si.
Conforme Wazlawick (2015), a análise de domínio está relacionada à descoberta das 
informações que serão gerenciadas pelo sistema. Ou seja, à representação e transforma-
ção dos dados ou da informação com o sistema.
Um termo que vem sendo bastante discutido ultimamente entre os desenvolvedores e 
stakeholders é o termo regra de negócio. Porém, nem sempre se dá a devida atenção 
a seu verdadeiro significado, o que acaba por levar à incompreensão algumas funciona-
lidades do software.
As regras de negócio estão intimamente relacionadas à organização, sua visão e mis-
são, e vinculadas aos objetivos que a organização pretende alcançar.
Apresento, na tabela 2, alguns exemplos de regras de negócio que não irão interfe-
rir na identificação de requisitos funcionais, como as RN 01 a 04. Note que estas são 
pontuais e caso não se vinculem a um software muito específico, em nada irão afetar a 
especificação de requisitos.
11
UNIDADE 
Tipos de Requisitos e sua Elicitação
Entretanto, as demais regras de negócio podem se tornar requisitos funcionais, con-
forme seu contexto – observe as diferenças entre elas e suas replicações “a” e “b”.
Tabela 2 – Regras de Negócios vs Requisitos Funcionais
RN RF Descrição
01 O horário de atendimento do trabalho é das 8h às 18h de 2ª a 6ª-feira.
02 Os funcionários devem portar crachá durante sua permanência na empresa.
03 O site deverá ser atualizado pelo responsável toda 6ª-feira.
04 A dedetização deverá ser feita trimestralmente e poderá ser feita até o 5º dia do primeiro mês do trimestre fiscal.
05 As contas devem ser pagas até o vencimento.
05a 01 As contas devem ser pagas até o vencimento (o sistema deve exibi-las em tela).
06 A ordem de compra somente poderá ser emitida após a escolha da melhor cotação.
06a 02 A ordem de compra somente poderá ser emitida após a escolha da melhor cotação (escolha automática pelo 
sistema).
07 Os recebimentos podem ser por cartão de débito ou crédito.
07a 03 Os recebimentos podem ser por cartão de débito ou crédito (deve existir uma interface com o banco).
08 Para cada venda realizada, deverá ser emitida eletronicamente a nota fiscal.
08a 04 Para cada venda realizada deverá ser emitida eletronicamente a nota fiscal (deve existir link automático para isto).
09 Somente o coordenador poderá autorizar (assinar) compras acima de R$ 5000,00.
09a 05 Somente o coordenador poderá autorizar (assinar pelo sistema) compras acima de R$ 5000,00.
10 Cada cotação deverá ser feita com no mínimo 5 fornecedores diferentes.
10a 06 Cada cotação deverá ser feita com no mínimo 5 fornecedores diferentes (o sistema deve exibi-los).
10b 07 Cada cotação deverá ser feita com no mínimo 5 fornecedores diferentes (o sistema deve exibi-los, aceitar as 
escolhas do comprador e enviar pedido de cotação por e-mail).
Os requisitos funcionais, derivados ou não de uma regra de negócio, podem gerar um 
ou mais requisitos não funcionais, também de acordo com o contexto ou situação apre-
sentada, que provocará seu desmembramento conforme se apresentem suas restrições.
Um outro aspecto que gera confusão quanto aos requisitos não funcionais é o fato 
de que às vezes estes não são derivados de requisitos funcionais, mas originam-se dire-
tamente das regras de negócio.
Observe bem isso na tabela 3.
Tabela 3 – Regras de Negócios vs Requisitos Funcionais vs Requisitos Não Funcionais
RN RF RNF Descrição
11 O atendimento por telefone não deverá exceder 5 minutos.
11 08 Se o atendimento por telefone atingir 5 minutos, o sistema deverá emitir um sinal 
para o operador.
11 09 09.01 Se o atendimento por telefone atingir 5 minutos, o sistema deverá emitir um sinal 
para o operador e deverá gravar um registro de atraso no LogSer. 
12 12x01 O tempo de resposta no acesso pela internet deve ser menor que 10 segundos.
13 13x01 O sistema deve ser executado em qualquer browser.
14 14x01 O número de abas no sistema não pode exceder a 7.
12
13
Uma das formas de se representar os requisitos funcionais e os requisitos não funcio-
nais deles derivados é apresentada na Tabela 4.
Tabela 4 – Regras de Negócios vs Requisitos Funcionais vs Requisitos Não Funcionais
F1 Registrar empréstimos Oculto ( )
Descrição: O sistema deve registrar emprestimos de fitas, indicando o cliente e as fitas que foram 
emprestadas, bem como a data de empréstimo e valor previsto para pagamento na devolução.
Requisitos Não Funcionais
Nome Restrição Categoria Desejável Permanente
NF 1.1 Controle 
de Acesso
A função só pode ser acessada 
por usuario com perfil de 
operador ou superior.
Segurança ( ) (X)
NF 1.2 
Identificação 
de Fitas
As fitas devem ser identificadas 
por um código de barras Interface ( ) (X)
NF 1.3 
Identificação 
do Cliente
O cliente deverá ser identificado 
a partir de seu nome Interface ( ) ( )
NF 1.4 Tempo 
de Registro
O tempo para registro de casa 
fita deve ser inferior a um 
segundo.
Performance (X) ( )
NF 1.5 Janela 
única
Todas as funções relacionadas 
a empréstimos devem ser 
efetuadas em uma única janela.
Interface (X) (X)
… … … … …
F2 Calcular Descontos Oculto (X)
Descrição: O sistema deve calcular descontos nos empréstimos em função da política da empresa.
Requisitos Não Funcionais
Nome Restrição Categoria Desejável Permanente
NF 2.1 Descoto 
de Fim de 
Semana
Nos fins de semana, usuários que 
levam 4 fitas pagam apenas 3. Especificação ( ) ( )
… … … … …
Fonte: Wazlawick (2015).
Como vimos, há regras de negócio que se tornam ou não requisitos funcionais, 
assim como há regras de negócio que se tornam requisitos não funcionais e requisitos 
funcionais que contém ou não requisitos não funcionais.
A segurança na identificação das regras de negócio e dos requisitos funcionais e 
não funcionais está diretamente relacionada com a fase de obtenção de requisitos. E 
esta com as técnicas disponíveis para essa finalidade e, claro, com as habilidades do 
desenvolvedor.
Uma das técnicas é o Brainstorm, realizado em sessões sucessivas ou programadas 
especificamente, com a reunião de (poucas) pessoas com diferentes perfis e que, na 
presença de um facilitador, apresentam e aceitam todos os tipos de sugestão para 
posteriormente filtrá-las após discussão.
13
UNIDADE 
Tipos de Requisitos e sua Elicitação
Outra técnica utilizada é a de Casos de Uso (ou Cenários), onde a elaboração deste 
diagrama da UML facilita o trabalho de identificação das necessidades dos usuários, com 
respectivos processos e subprocessos.
São situações descritas que explicam como um sistema poderá ser usado. Nas sessões 
de interação é demonstrado como o usuário irá interagir. O termo caso de uso ou use 
case pode ser usado nessas reuniões. Pode-se, inclusive, descrever o caso de uso em 
detalhes, identificando os atores envolvidos, as principais funcionalidades e a interação 
entre atores.
Detalhando-se o caso de uso, podem-se incluir informações diversas, tais como nome 
do cenário, ator(es), pré-condição, fluxo normal, fluxos alternativos e pós-condição.
Uma técnica que muitos desenvolvedores esquecem que existe e acabam por não 
utilizar é a de documentos. As comunicações internas das empresas são uma fonte 
fantástica de informação sobre um processo que será automatizado, assim como os 
documentos gerados ou utilizados, como gráficos, listas, tabelas ou relatórios.
As normas e procedimentossão outras importantes fontes de informação, pois muitas 
das regras de negócio estão lá registradas e sempre irão contribuir com o desenvolvedor 
em algum momento do projeto. O mesmo raciocínio quanto a livros ou revistas técnicas 
ou outras fontes de informação, no mínimo, irão contribuir com o desenvolvedor para 
entender a base do negócio ou do processo – até para se situar ou se preparar para 
conversar com os usuários. Uma fonte que requer maiores comentários é a legislação ou 
normas regulatórias de órgãos, entidades ou clientes e fornecedores.
A entrevista, por outro lado, é uma das técnicas mais utilizadas e permite o contato 
visual e maior envolvimento dos usuários. Essa técnica faz o questionamento dos 
stakeholders sobre o funcionamento do processo e podem ser fechadas, caso já se tenha 
perguntas pré-definidas ou abertas quando as respostas às perguntas básicas geram 
novas perguntas, visando assim, explorar ao máximo o conhecimento do stakeholder.
A técnica conhecida como etnografia deve ser utilizada quando se quer ter uma 
visão qualitativa ou quantitativa sobre o funcionamento de um processo. É a técnica 
de observação direta ou indireta utilizada para a compreensão do funcionamento do 
processo na prática e melhor entendimento sobre os requisitos sociais e organizacionais. 
Visa observar suas atividades, entender os conceitos envolvidos, escrevê-los e analisá-los 
para novas proposições ou complementos da coleta de dados.
A técnica de JAD - Joint Application Design promove cooperação, entendimento e 
trabalho em grupo entre as partes interessadas, aplicando-se dinâmica de grupo, técnicas 
visuais, documentação padrão e mantendo o processo organizado e racional, isso facilita 
a criação e a visão compartilhada do que o produto de software deve ser. As sessões 
de JAD devem ser programadas periodicamente, ter um grupo fechado (que poderá 
convidar algum outro stakeholder) e manter as pautas e atas devidamente elaboradas e 
cumpridas.
14
15
Flip Chart
Lousa Magnética
Janela de
Despesas
Gerais
AGENDA
Overview
Scanner
Impressora
Flip Chart
(Grá�cos)
Projetor
Name Tents
Figura 3 – Reunião de JAD
A técnica do ponto de vista visa conhecer, entender e especificar os vários entendimentos 
de cada um dos stakeholders envolvidos em um processo. Para o desenvolvedor, esta 
técnica é muito rica, pois permite conhecer uma situação ou um fato sob perspectivas 
diferentes, pois cada indivíduo tem uma percepção (ou entendimento) de um processo, 
cada qual com suas atividades, dificuldades e necessidades.
Outra técnica que vem sendo utilizada e bastante comum nos processos ágeis é a 
técnica de prototipação, onde as situações são apresentadas, discutidas e representadas 
em diagramas que permitem rápido e fácil entendimento. Os diagramas mais utilizados 
são o diagrama de classe da UML ou de caso de uso e, nas aplicações mais antigas, os 
(ainda) usados diagramas de fluxo de dados e de contexto.
O questionário é uma boa técnica a ser aplicada para economia de tempo e de 
orçamento, sendo adequado para projetos piloto que envolvem mais de uma unidade 
federativa, exige muito tempo para ser elaborado de forma adequada, pois deve ser 
preparado levando em conta também as dificuldades de tempo que o respondente 
fatalmente terá. Deve ser objetivo, tal qual uma questão de múltipla escolha, e com 
resultados esperados e já previamente identificados.
As técnicas de especificação de requisitos auxiliam a reduzir o custo do desenvolvimento 
e das manutenções em software e colaboram substancialmente para a qualidade na 
implementação de uma solução que atenda às reais necessidades dos usuários.
15
UNIDADE 
Tipos de Requisitos e sua Elicitação
Para Pfleeger (2004), “É importante que, ao definirmos os requisitos, possamos 
identificar se: estes estão corretos, são consistentes, estão completos, são realistas, se 
cada requisito descreve algo necessário ao cliente, se estes podem ser verificados ou 
rastreados etc.”
O mesmo autor sugere que o documento de definição de requisitos contenha o que 
o desenvolvedor precisa saber e o que o cliente gostaria de ver: o propósito geral do 
software, os fundamentos e objetivos de desenvolvimento do sistema, a descrição da 
abordagem que será utilizada, as características detalhadas do produto e seu ambiente 
operacional.
O documento de especificação de requisitos será o resultado obtido com as técnicas 
e conceitos que apresentamos nesta unidade.
16
17
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Introduction – wath is UML
Introduction – wath is UML. Acesso em: 06/04/2018.
https://goo.gl/s8TT6V
Quality Function Deployment
Quality Function Deployment. Acesso em: 06/04/2018.
https://goo.gl/rQgrWh
 Livros
Gerenciamento de requisitos
KERR, Eduardo Santos. Gerenciamento de requisitos. São Paulo, Pearson, 2015. 
(e-book)
 Leitura
Especificação de Requisitos no Domínio de Sistemas de Informação com o Uso de Padrões
BARCELOS, Leonardo e PENTEADO, Rosângela Penteado. Especificação de Requi-
sitos no Domínio de Sistemas de Informação com o Uso de Padrões. Acesso em: 
06/04/2018.
https://goo.gl/ejviJ4
Requirements Engineering Practices in Global Software Engineering Organizations
REZA, Ahmad Yandriansyah. Requirements Engineering Practices in Global Softwa-
re Engineering Organizations. Acesso em: 06/04/2018.
https://goo.gl/XLkDu1
A contribuição do JAD para o levantamento de Requisitos
A contribuição do JAD para o levantamento de Requisitos. Acesso em: 06/04/2018.
https://goo.gl/md3a99
Fundamentos básicos de UML
Fundamentos básicos de UML. Acesso em: 06/04/2018.
https://goo.gl/WGwC6X
17
UNIDADE 
Tipos de Requisitos e sua Elicitação
Referências
FOGGETTI Cristiano, ORG. Gestão ágil de projetos. São Paulo, Pearson, 2015. (e-book).
PAGE-JONES, Meilir. Fundamentos do desenho orientado a objetos com
UML. São Paulo: Makron Books, 2001. (e-book).
PFLEEGER, S. L. Engenharia de software - teoria e prática. 2.ed. São Paulo: Pear-
son/Prentice Hall, 2004. (e-book).
PRESSMAN, R. S. Engenharia de software. 7.ed. Rio de Janeiro: McGraw-Hill do 
Brasil, 2011. (e-book).
SCHACH, S. R. Engenharia de software: os paradigmas clássico & orientado a obje-
tos. 7. ed. São Paulo: Bookman, 2009.
SOMMERVILLE, I. Engenharia de software. 9.ed. São Paulo: Pearson, 2001. (e-book).
VAZQUEZ, Carlos E; SIMÕES, Guilherme S. Engenharia de requisitos. São Paulo: 
Brasport, 2016.
WAZLAWICK, Raul Sidnei. Análise e design orientados a objetos para sistemas de 
informação: modelagem com UML, OCL e IFML. 3.ed. Rio de Janeiro: Campus, 2015.
18