REQUISITOS

requisitar é pedir ou requerer algo ou alguém de modo oficial ou formal

“requisito” é aquilo que é necessário e indispensável; uma condição indispensável; uma exigência

Classificação quanto ao nível de abstração:

Requisitos de descrições, em linguagem natural e com diagramas, de quais serviços o sistema deve fornecer e
Usuário as restrições sob as quais deve operar; alto nível de abstração e poucos detalhes, feitos para
serem lidos por pessoas leigas – podem ser funcionais ou não funcionais
ex: O sistema deve fornecer um gráfico comparativo entre as vendas previstas e as realizadas

Requisitos de descrições detalhadas sobre as funções, operações e restrições de sistema que definem
Sistema exatamente o que deve ser implementado; baixo nível de abstração e muitos detalhes, feitos
para serem lidos por pessoas experientes – podem ser funcionais ou não funcionais

Ao escrever requisitos, deve-se considerar quem serão seus leitores, uma vez que eles possuem níveis diferentes de
conhecimento, portanto os requisitos devem ter níveis diferentes de detalhamento

documentação de requisitos deve conter duas perspectivas: uma voltada para o cliente, em linguagem
compreensível por ele, e outra voltada para o desenvolvedor, em uma linguagem técnica de modelagem

Classificação quanto à qualidade:

Quality Function técnica de gestão da qualidade aplicada ao levantamento de requisitos que traduz as
Deployment (QFD)/ necessidades do cliente em requisitos técnicos buscando maximizar a satisfação do
Disponibilização da cliente e enfatizando o entendimento do que é valioso para o cliente
Função de Qualidade

Requisitos Normais refletem os objetivos e metas estabelecidos para um produto ou sistema durante reuniões
com o cliente; se esses requisitos estiverem presentes, o cliente fica satisfeito; poderiam
ser tipos de displays gráficos solicitados, funções de sistema específicas e níveis de
desempenho definidos; equisitos completamente normais para o contexto do negócio;

Requisitos Esperados estão implícitos no produto ou sistema e podem ser tão fundamentais que o cliente não os
declara explicitamente; ausência será causa de grande insatisfação; seria um relatório
com todos os livros encontrados a partir do título de entrada; usuário sequer precisa
especificar para os desenvolvedores;

Requisitos vão além da expectativa dos clientes e demonstram ser muito satisfatórios quando
Fascinantes presentes; ex:o software para um novo celular vem com recursos-padrão, mas junto vem
um conjunto de capacidades não esperadas; por vezes, nem o usuário tinha pensado em
pedir isso, mas o programador foi lá e implementou – supera as expectativas dos clientes

Classificação quanto à evolução:

Requisitos diretamente ligados a atividade principal da organização; concebidos com a essência de

 Permanentes/ um sistema e seu domínio da aplicação, e mudam mais lentamente que requisitos
Requisitos Estáveis voláteis; termo permanente dá a impressão de que os requisitos não mudam e nós
sabemos que requisitos sempre mudam; requisitos permanentes são mais estáveis e que
mudar pouco ou demoram bastante para mudar; pode mudar uma coisa ou outra, mas
esses requisitos são mais estáveis com o passar do tempo

Requisitos específicos para a instanciação de um sistema em um ambiente ou um cliente particular e

Voláteis/Instáveis são mais propensos à mudança; modificam-se quando o sistema está em
desenvolvimento ou em uso; subclassificações:

Mutáveis modificam em função de mudanças no ambiente no qual o

sistema opera; exemplo: os requisitos para um sistema que
calcula taxas de dedução que evoluem conforme as leis fiscais
são atualizadas

Emergentes não podem ser completamente definidos quando o sistema é

especificado e emergem; à medida que a compreensão do cliente
sobre o sistema se desenvolve; eles só aparecerão durante o
desenvolvimento

Consequentes baseados em suposições de como o sistema será utilizado, isto é,

são resultado da introdução do sistema no ambiente do usuário;
usuário percebe as necessidades enquanto utiliza sistema e
esses requisitos são uma consequência do uso

De requisitos que dependem de outro equipamento, processo,

Compatibilidade componente ou elemento; se outros elementos mudam, esses
requisitos também mudam; requisitos menos comuns, mas que
também ocorrem;

Classificação quanto à funcionalidade:

Requisitos ações ou funcionalidades que o sistema deve fornecer para atingir seus objetivos;
Funcionais dependem do tipo de software, dos usuários esperados e do tipo de sistema onde o
software será implantado e fazem parte da arquitetura de um sistema; o que o sistema
deve fazer;

Problemas dos Requisitos Funcionais⇒ descrições de requisitos ambíguos, que permitem

diversas interpretações; há também requisitos incompletos, que não descrevem toda a
funcionalidade do serviço; e há requisitos inconsistentes, que contradizem outros
requisitos do sistema
Exemplos de Requisitos Funcionais: Pensemos em um Requisito do Outlook: Sistema
deverá fornecer opção de filtrar e-mails por Assunto e Anexos. Pensemos em um
 Requisito do Youtube: Sistema deverá reagir com suspensão de vídeos que ferem direito
autoral. Pensemos em um Requisito do GoogleMaps: Sistema deverá procurar rua mais
próxima, caso não encontre a desejada

Requisitos restrições ou condições estipuladas sobre as quais o sistema deve funcionar; não estão
Não-Funcionais diretamente relacionados às funções específicas do sistema, mas às gerais – e podem
incluir restrições de tempo, restrições de processo de desenvolvimento, restrições
impostas por padrões, entre outras; podem ser mais críticos que os funcionais e sempre
devem ser verificáveis; podem ser mais críticos que os funcionais e sempre devem ser
verificáveis; utilizam-se medidas que possam ser testadas ou mensuradas; raramente
associados às características individuais do sistema; qualidades globais de um software,
como manutenibilidade, usabilidade, desempenho, custos e várias outras; descritos de
maneira informal e, segundo Sommerville, geralmente afetam a arquitetura do sistema;

Problemas de Requisitos Não-Funcionais⇒ difíceis de se especificar objetivamente;

requisitos conflitantes; requisitos conflitantes;
Exemplos de Requisitos Não-Funcionais: Pensemos em um Requisito do Whatsapp:
Sistema deverá fornecer disponibilidade mínima de 99,8%. Pensemos em um Requisito
do Facebook: Sistema deverá ser desenvolvido utilizando a linguagem Java. Pensemos
em um Requisito do Android: Sistema deverá ser capaz de rodar com apenas 1Gb de
RAM. Pensemos em um Requisito da NASA: Sistema deverá funcionar em uma Câmera
4K captando infravermelho e resistente a variações de temperatura.EX2: Responder ao
clique único do usuário em qualquer botão da interface; Restaurar os dados
automaticamente após falhas não programadas; tempo de resposta, utilização de
volumetria estática, escalabilidade, disponibilidade, segurança e usabilidade;

Sommerville: a requisito pode parecer-se inicialmente não funcional, mas quando desenvolvido com mais
distinção entre esses detalhes pode dar origem a uma série de novos requisitos funcionais; ao discutirmos sobre
diferentes tipos de requisitos devemos levar em conta que na realidade a distinção entre eles é artificial;
requisitos não é tão
clara como sugere
essas definições

Classificação quanto à origem⇒ os requisitos não-funcionais também podiam ser agrupados por meio de suas
características comuns:

Requisitos de especificam o comportamento do produto; ex: especificam o comportamento do produto;

Produto

Requisitos derivados de políticas e procedimentos da organização do cliente e do desenvolvedor; ex:

Organizacionai padrões de processo que devem ser usados, linguagem de programação ou o método de projeto
s usado, e requisitos de entrega que especificam quando o produto e a sua documentação devem
ser entregues

Requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento; ex:

Externos interoperabilidade que define como o sistema interage com outros sistemas, requisitos legais
que devem ser seguidos, requisitos éticos sistema para assegurar que ele será aceito por todos;
Engenharia de Requisitos:

formulação, análise, documentação e manutenção de requisitos de um sistema

processo formal, sistêmico, metodológico, processual, repetível, etc.

sequência de passos repetíveis e documentados

capaz de encontrar a melhor solução viável no momento

impossível satisfazer absolutamente todas as expectativas dos clientes, na medida em que requisitos podem ser
bastante complexos e voláteis⇒ requisitos são entidades vivas que vão mudando o tempo todo por diversos
motivos

fases do Pressman:

concepção ●​ estabelecer um entendimento básico do problema;

 ●​ quem são os envolvidos, a natureza da solução e iniciar o processo de comunicação
entre clientes e colaboradores.

levantamento ●​ a descobrir o que o cliente deseja em seu sistema;

●​ participação do stakeholders e faz três perguntas: Qual o objetivo do produto? Como o
produto se enquadra nas necessidades do negócio? Como o produto será utilizado?.

elaboração/ ●​ informações obtidas do cliente durante a concepção e levantamento são expandidas e

Análise refinadas em um modelo, definindo o domínio do problema;
●​ modelagens de cenários de interação do usuário com o sistema e modelagens das
classes envolvidas;
●​

negociação ●​ consenso sobre os conflitos entre clientes e usuários;

●​ requisitos são avaliados junto ao cliente e podem se combinar, excluir ou até mesmo
inserir novos requisitos.

especificação/ ●​ produto final do engenheiro de requisitos⇒ documento escrito, um modelo gráfico,

documentação cenários de uso, protótipos, etc;
●​ apresentação formal dos dados obtidos até o momento de modo que possa guiar o
desenvolvimento futuro do software.

validação ●​ produtos de trabalho são avaliados quanto a sua qualidade por todos os envolvidos
(clientes, colaboradores e usuários);
●​ busca erros de interpretação, ambiguidades e omissões.

gestão ●​ identificar, controlar e rastrear requisitos e mudanças nos requisitos a qualquer

momento;
●​ mudanças em um requisito podem afetar diversos outros requisitos.
Sommerville:

objetivo da engenharia de requisitos é criar e manter um documento de requisitos de sistema

resultado do Estudo de Viabilidade é o Relatório de Viabilidade; o resultado da Elicitação e Análise de Requisitos

é um conjunto de Modelos do Sistema; o resultado da Especificação de Requisitos são os Requisitos de Usuário
e de Sistema; e o resultado da Validação de Requisitos é o famoso Documento de Requisitos

fases:

Estudo de ●​ verificar se as necessidades identificadas dos usuários podem ser satisfeitas

Viabilidade por meio das tecnologias atuais de sistemas de software e hardware;
●​ resultado⇒ informações para que a alta direção da organização tome uma
decisão mais embasada quanto a prosseguir para uma análise mais detalhada
ou não;
●​ o sistema realmente agregará valor ao negócio? Ele será útil para a empresa?
Ele será rentável? Qual é o retorno de investimento que ele será capaz de
realizar? É viável tecnologicamente e financeiramente?
●​ conjunto preliminar de requisitos de negócio, um esboço da descrição do
sistema e da forma como o sistema pretende apoiar os processos de negócios
da organização;
●​ fase seguinte utiliza as informações do estudo de viabilidade como base para o
levantamento de requisitos;
●​ estudo curto, bem focado e preferencialmente barato, devendo ser realizado
no início do processo de engenharia de requisitos e, ao final, deverá entregar
um relatório de viabilidade⇒ se você perder muito tempo desenvolvendo o
estudo ou se ele for caro demais, pode acabar não valendo a pena sequer
fazê-lo;responder três questões em que – caso alguma delas tenha uma
resposta negativa – o projeto não deve seguir adiante⇒ sistema contribui para
os objetivos gerais da organização? sistema pode ser implementado com
tecnologia atual e dentro do custo e prazo? sistema pode ser integrado a
outros sistemas já implantados?
Elicitação e Análise ●​ engenheiros de software trabalham com os clientes e usuários finais do
de Requisitos sistema para aprender sobre o domínio da aplicação, quais serviços o sistema
deve fornecer, o desempenho esperado, restrições de hardware, entre outros
quesitos;
●​ levantamento e derivação de requisitos de sistema através da observação de
sistemas existentes, discussões com usuários e compradores potenciais,
análise de tarefas, entre outros;
●​ pode envolver o desenvolvimento de um ou mais modelos de sistema e
protótipos, que ajudam o analista a compreender o sistema a ser especificado;
●​ principais atividades:

Obtenção de Requisitos ●​ interação com os stakeholders;

●​ requisitos de domínio também são descobertos
durante essa atividade;

Classificação e ●​ coleção de requisitos não estruturados, agrupa

organização de requisitos os requisitos relacionados e os organiza em
conjuntos coerentes

Priorização e negociação ●​ os requisitos poderão ser conflitantes;

de requisitos ●​ priorizar os requisitos e resolver conflitos por
meio da negociação

Documentação de ●​ requisitos são documentados e colocados na

requisitos próxima volta da espiral;
●​ produzidos documentos de requisitos formais ou
informais

●​ assegurar uma cobertura ampla dos requisitos de um sistema de software,

utilizam-se as seguintes técnicas:

Entrevistas ●​ podem ser formais ou informais com os stakeholders;

●​ equipe formula questões para os stakeholders sobre o
sistema que eles usam e o sistema a ser desenvolvido⇒
requisitos são derivados a partir das respostas;
●​ entrevistas abertas⇒ não há um roteiro predefinido;
discussões completamente abertas raramente funcionam
bem;
●​ entrevistas fechadas⇒ há um roteiro predefinido; maioria
das entrevistas requer algumas perguntas como ponto de
partida e para manter o foco no sistema a ser desenvolvido;
●​ não são tão úteis para compreender os requisitos do
domínio da aplicação;
●​ não é eficiente para elicitação de conhecimentos sobre os
requisitos e as restrições organizacionais, pois existem
relacionamentos sutis de poder e influência entre os
stakeholders;
●​ a maioria das pessoas é relutante em discutir questões
políticas e organizacionais que podem afetar os requisitos;
●​ Entrevistas Formais:
➔​ Pirâmide⇒ começa com perguntas mais detalhadas
e termina com questões mais genéricas;
➔​ Funil⇒ começa com perguntas mais genéricas e
termina com perguntas mais detalhadas;
➔​ Diamante⇒ mescla de ambos –começa com
perguntas mais detalhadas, depois são feitas
perguntas mais genéricas e termina com perguntas
mais detalhadas novamente.

Etnografia ●​ técnica de observação utilizada para compreender os

requisitos organizacionais e sociais;
●​ analista dentro do campo de atuação dos usuários,
observando o trabalho diário anotando as tarefas reais em
que os participantes estão envolvidos;
●​ utilizada em conjunto com outras técnicas;
●​ isoladamente ela não é muito eficaz na elicitação;
●​ descobrir os requisitos implícitos de sistema que refletem os
processos reais, e não os processos formais, com os quais
as pessoas estão realmente envolvidas;
●​ pessoas frequentemente consideram muito difícil articular
detalhes de seu trabalho rotineiro, visto que muitos passos
são secundários e irrelevantes para elas⇒ elas
compreendem seu próprio trabalho, mas podem não
 compreender seu relacionamento com o trabalho de outros
na organização;
●​ fatores sociais e organizacionais, que afetam o trabalho,
mas que não são claros e óbvios para as pessoas, podem
somente se tornar claros quando examinados por um
observador imparcial.

Cenários ●​ mais fácil relatar exemplos da vida real do que abstrair

descrições;
●​ pessoas podem compreender e criticar um cenário de como
interagiriam com um sistema de software;
●​ podem usar as informações obtidas nessa discussão para
elaborar os requisitos reais do sistema de software;
●​ cenário abrange uma ou mais interações possíveis;
●​ uso de cenários para descrever requisitos é parte integrante
dos métodos ágeis, como a Extreme Programming;
●​ cenário começa com um esboço da interação e, durante a
elicitação, os detalhes são adicionados para criar uma
descrição completa dessa interação;
●​ elicitação baseada em cenários pode ser realizada também
de informalmente;
●​ engenheiros de requisitos trabalham com os stakeholders
para identificar cenários e captar seus detalhes em forma de
textos, diagramas, imagens, eventos, casos de uso, etc.

Questionários ●​ formulários distribuídos aos stakeholders com questões

pré-definidas;
●​ útil quando a quantidade de stakeholders é muito grande,
quando não seria viável obter informações por meio de
entrevistas individuais;
●​ baixo custo, é fácil de aplicar, pode atingir várias pessoas,
demanda menos tempo e fornece rápido feedback;
●​ falta de interação, perguntas pouco objetivas, difícil
compreensão das perguntas, entre outros;
●​ questões são dirigidas por escrito aos participantes com o
objetivo de ter conhecimento sobre opiniões das mesmas
questões – são autoaplicáveis, pois o próprio informante
responde.

Workshop de ●​ reunião estruturada e intensiva entre analistas e usuários

Requisitos com o intuito de obter um conjunto de requisitos bem
definidos;
●​ há um facilitador neutro⇒ atividades de logística e
promoção de momentos de descontração, como forma de
dinamizar o trabalho em equipe;
●​ pode utilizar outras técnicas em conjunto como
brainstorming ou interpretação de papéis;
●​ devem fazer parte do grupo uma equipe de analistas e uma
seleção/amostra dos stakeholders que melhor representam
a organização e o contexto em que o sistema será utilizado;
 ●​ realizado por convocação por dia e horário, pode ocasionar
problemas por conta da presença física dos stakeholders,
mas isso tem mudado pós-pandemia;

Brainstorming ●​ ocorrida em grupo em ambientes informais⇒ toda ideia

(Tempestade deve ser levada em consideração, sendo proibida a crítica a
de Ideias) qualquer sugestão dada, e encorajada, inclusive, a criação
de ideias que pareçam estranhas ou exóticas;
●​ explorar a potencialidade criativa de um grupo – um
facilitador organiza e prioriza os resultados;
●​ democratiza a participação de membros do grupo;
●​ depende da disponibilidade dos integrantes;
●​ utilizado em conjunto com outras técnicas, tais como
workshops de requisitos.

Leitura de ●​ coletar informações que são geralmente mais difíceis de se

Documentos obter por meio de entrevistas, questionários e observações
sociais, como – por exemplo – histórico da organização,
cultura e hábitos internos, relacionamentos setoriais,
informações financeiras e direcionamentos futuros;
●​ muito utilizadas no contexto de sistemas legados;
●​ estudo e reutilização de documentação de diferentes
naturezas, para a identificação de requisitos a serem
implementados no sistema que se está modelando, podem
ser utilizados.

JAD (Joint ●​ reunir os usuários e desenvolvedores em um workshop

Application estruturado para levantar requisitos e promover a tomada de
Design decisões por meio de diversos tipos de dinâmicas de grupo,
técnicas visuais, processos racionais e até documentação;
●​ interativa e promove a participação ativa dos envolvidos –
inclusive dos tímidos;
●​ três fases principais:
➔​ customização⇒ analista prepara as tarefas para as
sessões como organizar os times, preparar o
material, entre outros;
➔​ sessões⇒ reuniões com os stakeholders; resolvem
dificuldades entre as partes enquanto se dá o
desenvolvimento do sistema para a empresa;
➔​ agrupamento⇒ visão genérica sobre o sistema; os
requisitos levantados nas fases anteriores são
convertidos em documentos de especificação de
requisitos.
●​ discussão com os stakeholders continua até o fim do
levantamento de requisitos;

●​