Slides Aulas Parte1

Prof.
Carlos Alberto
Prof. Carlos Alberto
Introdução
 Problemas a serem resolvidos por engenheiros de
software muitas vezes são imensamente complexos;
 Compreender a natureza do problema pode ser

bastante difícil, principalmente quando se trata de um
sistema novo;
 Como estabelecer exatamente o que o sistema deve

fazer?
 Esse é o desafio da Engenharia de Requisitos - ER.
Definição
 Disciplina da Engenharia de Software (ES) que consiste
no uso sistemático e repetitivo de técnicas para cobrir
atividades de obtenção, documentação e
manutenção de um conjunto de requisitos para
softwares que atendam aos objetivos de negócio e
sejam de qualidade.
Fonte: FATTO, 2017

Por que “engenharia”?
 Seria uma apropriação do prestígio da engenharia para

valorizar o assunto?
Significado de engenharia
 “Conjunto de técnicas e métodos para aplicar o
conhecimento técnico e científico na planificação,
criação e manutenção de estruturas, máquinas e
sistemas para benefício do ser humano”.
Fonte: "engenharia", in Dicionário Priberam da Língua Portuguesa [on line], 2008-2013,

https://www.priberam.pt/dlpo/engenharia [consultado em 21-04-2017].
Significado de engenharia
 “aplicação de métodos científicos ou empíricos à
utilização dos recursos da natureza em benefício do
ser humano”.
Fonte: https://www.google.com.br [consultado em 21-04-2017].
 “a palavra engenharia traz os conceitos de criação,

construção, análise, desenvolvimento e manutenção,
fazendo uso de conhecimentos científicos e de técnicas
empíricas”.
Fonte: http://www.dicionarioinformal.com.br/engenharia/ [consultado em 21-04-2017].
Processo geral de engenharia
 Um processo geral de engenharia pode ser explicado da
seguinte forma:
Fonte: VAZQUEZ E SIMÕES, 2016

Processo geral de engenharia
 A Engenharia de Requisitos está completamente

alinhada a esse processo geral.
ER no contexto da ES
 A ISO1 (2010) define Engenharia de Software como:
 “(1) a aplicação sistemática de conhecimento tecnológico

e científico, métodos e experiência ao projeto,
implementação, teste e documentação de software;”
 “(2) a aplicação de uma abordagem sistemática,

disciplinada quantificável ao desenvolvimento,
operação e manutenção de software; ou seja, a aplicação
de engenharia de software.”
1 - International Organization for Standardization (Organização Internacional de Normalização)

 Destaca-se palavra “disciplinada”:
 O conhecimento e as habilidades relativas às tarefas da

engenharia de software são organizados em disciplinas
ou áreas de conhecimento.
 Não existe consenso ou referencial único sobre quais
sejam as disciplinas.
 Existem modelos de referência:

 RUP (Processo Unificado da Rational/IBM);
 SWEBOOK (Software Engineering Body of Knowledge)

do IEEE;
 Áreas de processo do CMMI (Capability Maturity Model

– Integration) do SEI (Software Engineering Institute).
 No Processo Unificado da Rational/IBM (RUP),
disciplinas são categorias que agregam atividades
similares:
 Disciplinas de engenharia
 Disciplinas de apoio
 Disciplinas de engenharia
 Modelagem de negócio
 Engenharia de requisitos
 Análise e projeto
 Implementação
 Engenharia de testes
 implantação
 Disciplinas de apoio
 Gerência de configuração e mudança
 Gerência de projetos
 Ambiente
 Disciplinas no RUP
Fonte: FATTO, 2017

 No SWEBOK, são dez áreas de conhecimento (KA –
Knowledge Area)
 Requisitos de software
 Projeto (design) de software
 Construção de software
 Testes de software
 Manutenção de software
 Gerência de configuração de software
 Gerência de engenharia de software
 Processo de engenharia de software
 Métodos e ferramentas de engenharia de software
 Qualidade de software
 Enquanto o RUP e o SWEBOK abordam a Engenharia
de Requisitos como uma única disciplina ou área de
conhecimento, no CMMI utiliza-se o termo “área de
processo”.
 Duas áreas abordam a ER:

 Desenvolvimento de requisitos (RD – Requirements
Developed)
 Gestão de requisitos (REQM – Requirements

Management)
 Não importa o referencial utilizado para definir
engenharia de software, o tema requisitos é a base para
o trabalho das demais disciplinas.

ER em diferentes estratégias
 A falta de conhecimento ou habilidade em usar
adequadamente os modelos de referência (sequencial
ou iterativo) pode conduzir à utilização equivocada
destes em projetos reais;
 É comum, principalmente em organizações públicas e

empresas de grande porte, manter o desenvolvimento
sob uma forte orientação ao planejamento, deixando
pouco espaço para a mudança;
 A ER acaba se tornando vilã e o termo “requisito”
sendo confundido com:
 “Documentação”;
 Fase de acompanhamento do progresso de projetos.
 Nas exigências e expectativas do mundo atual, torna-se

um equívoco essa limitação.
 Na prática, acaba-se trabalhando muito próximo à

estratégia sequencial (modelo cascata).
 Estratégia sequencial para ordenamento do trabalho
de desenvolvimento

 Essa visão equivocada dos modelos de referência
sequencial e iterativo levou a movimentos como o
Manifesto Ágil, por exemplo:
 Extreme Programming (XP);
 Scrum
 Espalhar as atividades de requisitos ao longo de todo o
desenvolvimento produz melhores resultados:
 Maior ênfase inicialmente no entendimento dos

objetivos para o desenvolvimento e das suas restrições;
 Explorar a abrangência do produto, especificando as

principais atividades;
 As atividades da ER são intercaladas gradualmente na

exploração da profundidade do produto;
 Ciclos curtos de desenvolvimento (2 a 4 semanas).


 A disciplina de Engenharia de Requisitos demanda
mais esforço nas primeiras iterações do Processo
Unificado.
Fonte: FATTO, 2017

COnstrutive COst MOdel: modelo de estimativa
paramétrico baseado em pesquisas e dados históricos
 Esforço da Engenharia de Requisitos por fase

 Do desenvolvimento sequencial ao
desenvolvimento iterativo e incremental, sempre
haverá necessidade da Engenharia de Requisitos,
por mais “ágil” que seja a iniciativa.
 A ER facilita a interação com o cliente na

identificação e entendimento das suas
necessidades e na obtenção de um acordo sobre a
solução adotada;
 Os fluxos de trabalho da ER:
 Têm inicio com o entendimento da necessidade do

cliente; e
 Passam pelo acordo sobre a solução que será construída.

 A ER produz insumos para uso em uma variedade
de disciplinas da Engenharia de Software
O papel do analista
 De acordo com o portal Catho (CATHO, 2016)
 “realiza o levantamento de requisitos e especificação de

projetos de TI, desenvolvendo soluções para processos,
mapeamento e análise de negócio. Elabora a
documentação técnica de especificação de requisitos de
software e status report para a gestão de projetos”.
http://www.catho.com.br/profissoes/analista-de-requisitos
O papel do analista
 Perfil de quem desempenha esse papel (CATHO,
2016) :
 35% têm pós-graduação;
 37% têm graduação em Sistemas de Informação;
 Levaram 1 ano e 11 meses até chegar a esse cargo (a partir

do cargo anterior);
 56% têm inglês intermediário.

O papel do analista
 Características de um Engenheiro de Requisitos,
segundo Rupp e Pohl (2015)
 Papel Central. O Engenheiro de Requisitos

frequentemente é o centro das atenções do projeto.
Geralmente, somente ele tem contato direto com os
stakeholders.
O papel do analista
 Sete capacidades necessárias ao Engenheiro de
Requisitos:
1. Pensamento analítico. Habilidade para se

familiarizar com domínios desconhecidos, além de
compreender e analisar problemas e relacionamentos
complicados.
2. Empatia. Boa intuição e empatia são úteis na

negociação de acordos entre o grupo de stakeholders
para solucionar possíveis problemas e/ou conflitos.
O papel do analista
Requisitos:
3. Habilidades de comunicação. Par obter os requisitos

e interpretá-los corretamente e comunicá-los de
maneira adequada, é preciso habilidades de
comunicação.
4. Habilidades para resolver conflitos. Diferentes

opiniões de diferentes stakeholders podem causar
conflitos durante a engenharia de requisitos.
O papel do analista
Requisitos:
5. Habilidades de moderação. Deve ser hábil para fazer a

mediação entre opiniões diferentes e conduzir discussões.
Conversas individuais ou em grupo.
6. Autoconfiança. Sendo frequentemente o centro da

atenção, ocasionalmente está exposto à crítica também. É
preciso alto nível de autoconfiança e a capacidade de
defender suas opiniões, pois devem surgir fortes objeções.
Nunca se deve levar a crítica para o lado pessoal.
O papel do analista
Requisitos:
7. Persuasão. Deve ser capaz de representar os requisitos

em reuniões de equipe e apresentações. Além disso,
deve consolidar opiniões divergentes, facilitar uma
decisão em caso de desacordo e criar consenso entre os
stakeholders.
Requisito
 Alguns profissionais de software consideram que
“requisito” é sinônimo de “documentação”;
 A documentação é necessária para que a

informação não se perca e possa ser confirmada e
compartilhada;
Requisito
 Requisito está relacionado às necessidades
 (1) Uma condição ou capacidade necessária por um

usuário para resolver um problema ou alcançar um
objetivo (ISO/IEC/IEEE, 2010);
Requisito
 Requisito está relacionado às propriedades
(características) de um produto
 (2) Uma condição ou capacidade que deve ser atingida

ou possuída por um sistema ou componente de um
sistema para satisfazer um contrato, padrão,
especificação ou outro documento formalmente
imposto (ISO/IEC/IEEE, 2010);
Requisito
 Definição completa da (ISO/IEC/IEEE, 2010):
1. Uma condição ou capacidade do sistema, solicitada por
um usuário, para resolver um problema ou atingir um
objetivo.
2. Uma condição ou capacidade que deve ser atendida
por uma solução para satisfazer um contrato,
especificação, padrão ou quaisquer outros
documentos formais impostos.
3. Documentação da representação das condições ou
capacidades apresentadas nos dois itens anteriores.
Requisito
 Definição completa da (ISO/IEC/IEEE, 2010):
4. Uma condição ou capacidade que deve ser alcançada

ou possuída por um sistema, produto, serviço,
resultado ou componente para satisfazer um contrato,
padrão, especificação ou outro documento
formalmente imposto. Requisitos incluem as
necessidades quantificadas e documentadas, desejos e
expectativas do patrocinador, clientes e outras partes
interessadas.
 A definição (4) consolida, clarifica e complementa as

três anteriores.
Especificação de Requisitos
 Definição: contrato entre clientes e equipe de
desenvolvimento.
 Objetivos
 Documentar de forma fiel e completa todas as
necessidades dos clientes e obter um aceite sobre o que
se propõe entregar em termos de produto;
 Permitir que a equipe de desenvolvimento compreenda

exatamente o que os clientes desejam.
 É comum a especificação de requisitos conter:
 Visão geral
 Glossário
 Modelos do sistema
 Lista de requisitos funcionais
 Lista de requisitos não funcionais
 Especificação detalhada de requisitos

 Publico alvo: cliente e equipe de desenvolvimento
 Desafio: construir uma visão de especificação que seja

compreensível pelas várias pessoas no lado cliente
 Documento de requisitos orientado ao cliente é útil

para a equipe de desenvolvimento. Mas, o inverso não
é verdade.
 Nível de detalhe da especificação
 Detalhar pouco: pode levar a interpretações
equivocadas ou um número elevado de premissas;
 Detalhar demais: elemento paralisante do projeto.

Onera o projeto.
 Desafio: encontrar o equilíbrio do nível de detalhe.
 Equívoco comum: pensar que quanto mais detalhada a

especificação, melhor.
 Para reduzir a necessidade de detalhamento da
especificação, o manifesto ágil prega:
 “colaboração com o cliente mais que negociação de

contratos”.
 Princípio 4: “pessoas de negócio e desenvolvedores

devem trabalhar diariamente em conjunto por todo o
projeto”.
 Fatores para o nível de detalhe da especificação

Qualidade da Especificação
 Não existe especificação perfeita;
 Uma boa especificação deve atender a dois

objetivos:
 Ajudar os clientes a descrever com exatidão o que
desejam obter do projeto;
 Ajudar os desenvolvedores a entender exatamente o que
os clientes querem.
 A especificação deve evitar abordar questões relativas

ao design ou implementação;
 A Norma IEEE 830 (1998) fornece critérios de
qualidade para uma boa especificação de
requisitos, destacando as seguintes características:
 Correta
 Completa
 Clara
 Consistente
 A Norma IEEE 830 (1998) fornece critérios de
qualidade para uma boa especificação de
requisitos, destacando as seguintes características:
 Modificável
 Priorizada
 Verificável (ou testável)
 Rastreável
 Os critérios são úteis:
 Como referencial durante a elaboração da especificação
 Nas atividades de verificação e validação

A importância da ER
 Consequências de negligenciar a disciplina de
requisitos:
 Atraso no cronograma e custo adicional;
 Nível alto de defeito no software
 Software que não satisfaz plenamente as necessidades

do cliente.
 Casos famosos de falhas relacionadas à deficiência
no exercício da Engenharia de Requisitos:
 Sonda espacial Masr Climate Orbiter
 Míssil antibalístico Patriot
 Foguete Ariane 501 da Agência Espacial Europeia
 Arquivo virtual do FBI (Virtual Case File)

 Sonda espacial Masr
Climate Orbiter
 Lançada em dezembro
de 1998, ao entrar na
órbita de Marte foi
destruída;
 Prejuízo de US$ 125
milhões à NASA
 Pounds-seconds X
newton-seconds Fonte: VAZQUEZ E SIMÕES, 2016
 Míssil antibalístico Patriot
 Falha ao não interceptar um
míssil Scud do Iraque na
Guerra do Golfo na década de
1990;
 28 militares mortos e 98
feridos;
 Sub-rotina para obter maior
precisão nas informações do
relógio do sistema não foi
instalada em todas as partes
necessárias;
 Solução adotada: “reiniciar o
sistema sempre que possível”;
 Falha na avaliação do
impacto de mudança
 Foguete Ariane 501 da Agência
Espacial Europeia
 Explodiu 37 segundos após a
decolagem em 4 de junho de 1996;
 Dez anos de desenvolvimento e
custo de US$ 7 bilhões;
 Perda do foguete e sua carga:
prejuízo de US$ 370 milhões
 Causa da falha: perda total de
informações de orientação do
foguete;
 Provocou a falha: erros de
especificação e design do software
do sistema de referência inercial.
 Arquivo virtual do FBI (Virtual Case File)
 Início do desenvolvimento no ano 2000;
 Previsão de duração do projeto: 3 anos;
 Cinco anos depois o projeto foi abortado com custos de

US$ 170 milhões;
 Causas do fracasso: mudanças frequentes de requisitos,

alta rotatividade da gerência e aumento descontrolado
do escopo do projeto (requisitos acrescentados mesmo
com projeto atrasado).
 Constatações de um estudo do Project
Management Institute (PMI):
 47% dos projetos fracassam por deficiência no exercício
da Engenharia de Requisitos;
 Somente 20% das organizações pesquisadas possuem

alta maturidade com a Engenharia de Requisitos;
 Organizações com baixo desempenho na Engenharia de

Requisitos desperdiçam quase dez vezes mais dinheiro
em projetos que as de alto desempenho.
 Exemplos de motivos que potencializam a chance
de fracasso do projeto:
 Erros na estimativa de custo;
 Entrega de um produto que não satisfaça o cliente;
 Incorporar requisitos que não deveriam estar no escopo;

 Exemplos de motivos que potencializam a chance
de fracasso do projeto:
 O produto ser entregue sem cumprir com requisitos

necessários e que sequer foram identificados;
 Falhas na comunicação dos requisitos ao longo do

projeto;
 Há requisitos que são descobertos apenas com o uso de

protótipos, principalmente de usabilidade.
 Causas de defeitos em software:
 Segundo Casper Jones (2013), nos EUA, um em cada

cinco defeitos são originados de requisitos (20%);
 Dean Leffingwell (1997) argumenta que, em projetos

mais complexos, erros em requisitos são os mais
comuns;
 Causas de defeitos em software:
 Pohl (2011) afirma que erros em requisitos podem

corresponder a até 60% do total de erros no projeto,
considerando como erro requisitos que faltaram ser
implementados no produto;
 Jones (2012) destaca que as mudanças em requisitos

tendem a ter uma densidade de defeitos maior que os
requisitos originais.
 Custo do reparo de defeitos
 40% a 50% do esforço em projetos de software são gastos

em retrabalho para a correção de defeitos;
 A correção de um defeito produz 20% a 50% de chance

de se introduzir outro defeito no software;
 Esforço para encontrar e corrigir um defeito após a

entrega do software pode custar 100 vezes mais do que
corrigir esse defeito durante a elaboração de requisitos;
 Custo do reparo de defeitos

 Especificações de requisitos funcionam como um
ativo valioso na organização
 O trabalho de requisitos identifica, cria e estrutura o

conhecimento;
 É importante que seja documentado;
 Minimiza o impacto da rotatividade de pessoal na

equipe de projeto.
 Reflexão sobre a relevância da ER
 Área Acadêmica: a ER é apresentada como parte da
disciplina de Engenharia de Software e não como
disciplina específica;
 Visão superficial do tema
 Empresas: esforço de capacitação da equipe técnica

dedicada a ferramentas, às vezes até ferramentas de
gestão de requisitos;
 A ausência de uma base sólida dos conceitos dificulta
melhor proveito da ferramenta
 Reflexão sobre a relevância da ER
 Mercado de livros: poucas opções para livros específicos;
 Desenvolvimento de software vive de muitos

“modismos”
 “As ondas passam, ferramentas vêm e vão. E os
problemas continuam: projetos entregando produtos
que não satisfazem o usuário”.
 A maioria aprende na prática: um jeito caro de aprender;

Dificuldade na ER
 Comunicação
 Falta de clareza seja com as partes interessadas, seja com
os membros da equipe;
 Ambiguidade na nossa linguagem do dia a dia;
 Ruídos na comunicação
 Dificuldade de manter a sintonia de todos os envolvidos;
 Sugestão: desenvolver habilidades de comunicação e o
relacionamento interpessoal.
Dificuldade na ER
 Acesso às partes interessadas
 Falta de tempo ou interesse, por questões políticas,
sociais, culturais ou qualquer outro motivo;
 Não é demandante direta do projeto;
 É demandante direta do projeto;
 Empresas desejam adotar o desenvolvimento de projetos
ágeis, mas ignora a sua filosofia (pessoas do negócio e
equipe trabalhando em conjunto);
 Sugestão: se o analista de requisito não resolver, o
gerente de projetos (ou alguém com mais autoridade)
deve ser acionado.
Dificuldade na ER
 Indecisões/indefinições do usuário
 Dificuldade do usuário em saber o que quer;
 Dificuldade do usuário em se expressar corretamente;
 Postura passiva não condiz com o papel do analista de
requisitos;
 Sugestão: buscar métodos mais adequados para a
obtenção das informações.

Dificuldade na ER
 Requisitos implícitos
 Necessidades não atendidas no produto e que não foram
explicitadas antes;
 “É óbvio que o produto deveria ter isso!”;
 Quem é o culpado?
 Não há ferramenta ou técnica que garanta uma
especificação completa;
 Sugestão: conhecer bem o negócio da parte interessada.
Observação e prototipação ajudam a minimizar o
problema.
Dificuldade na ER
 Mudanças
 Mudanças que poderiam ser evitadas;
 Mudanças que fogem ao controle do analista;
 É ilusão querer produzir uma especificação de requisitos
que não será alterada.
 Sugestão: fazer um bom trabalho inicial de requisitos.
Um bom planejamento.
Dificuldade na ER
 Conflitos
 Requisitos inviáveis de atender simultaneamente;
 Informações inconsistentes sobre como funciona um
processo de negócio;
 Solicitações fora do escopo do projeto;
 Partes interessadas que são adversárias, antipáticas ou
hostis umas com as outras;
 Falta de sintonia entre as áreas de negócio envolvidas.
 Sugestão: boa habilidade de relações interpessoais.
Dificuldade na ER
 Resistência à mudança
 Novidades geram temor e/ou preocupação nas pessoas;
 Falhas na comunicação podem criar receios sobre a
mudança;
 Mudanças podem trazer perdas para algumas partes
interessadas;
 Dificuldade de cooperação;
 Sugestão: compreender o impacto que o projeto
acarretará a cada parte interessada. Usar métodos
apropriados para a obtenção das informações. Exercer
boa comunicação.
Dificuldade na ER
 Parte interessada não domina seu negócio
 Gestor novato;
 Gestor indicado por fatores políticos;
 Sugestão: buscar conhecer bem o negócio, através de
meio apropriados;
Dificuldade na ER
 Parte interessada não lê a especificação de
requisitos
 Partes interessadas não compreendem a importância da
especificação;
 A estratégia de apresentação da especificação pode estar
errada;
 Parte interessada já está (ou acha que está) ciente do que
será entregue;
 Sugestão: buscar estratégias de apresentação que
estimulem o interesse das partes. Há casos em que a
política é não seguir com o trabalho até a aprovação da
especificação.
Dificuldade na ER
 Partes interessadas insaciáveis com requisitos
 Necessidades nunca se esgotam;
 Quase sempre não é objetivo do projeto resolver todos os
problemas de uma parte interessada;
 Sugestão: boa delimitação do escopo do projeto.

Dificuldade na ER
 Consistência
O trabalho de requisitos desenvolvido de forma
evolutiva pode resultar em uma especificação final com
inconsistências;
 Solicitações de mudanças podem ocorrer;
 Pode haver mais de um autor para a especificação de
requisitos;
 Sugestão: usar uma metodologia de trabalho bem
definida.
Dificuldade na ER
 Necessidades vagas
 No inicio do trabalho as necessidades apresentadas são
mais ou menos vagas;
 Transformar necessidades vagas em necessidades claras
e específicas é trabalhoso;
 Especificação com requisitos vagos tem utilidade
comprometida;
 Sugestão: não concluir o trabalho enquanto houver um
nível alto de incerteza sobre as necessidades.
Dificuldade na ER
 Priorização
 A grande dificuldade é ter alguém que assuma a
responsabilidade da priorização;
 Priorizar é uma escolha difícil;
 Sugestão: mostrar eventuais impactos das decisões e
esclarecer melhor cada requisito, se necessário.

Domínio do Problema
 É onde surge o motivo para a mudança facilitada
pela Engenharia de Requisitos;
 É uma área (ou mais) sujeito à análise;
 O que motiva uma organização a agir?
 Componentes do domínio:
 Fronteiras que delimitam cada área;
 Partes interessadas chaves;
 Interações das partes interessadas com as áreas.

 Importância
 Delimita o escopo inicial de uma solução em termos

de áreas funcionais e processos de negócios;
 As partes interessadas chaves são o ponto de partida

para toda a atividade de Engenharia de Requisitos.
Requisitos de Negócio
 Declarações de mais alto nível de objetivos, metas ou
necessidades da organização;
 Descrevem as razões pelas quais um projeto foi

iniciado;
 Descrevem necessidades da organização como um

todo e não de grupos ou partes interessadas;
 A contínua mudança no equilíbrio entre as forças em
que a organização está inserida cria novas
necessidades de negócio:
 Problemas a serem resolvidos
 Oportunidades a serem aproveitadas
 Relacionadas a
 Alterações que se deseja operar
 Manutenção das condições atuais
 Descrevem metas e objetivos que uma organização
pretende atingir
 Definem métricas usadas para medir o sucesso do

projeto. Exemplos:
 Reduzir 90% da devolução de cartas por endereço
incompleto (problema).
 Aumentar 20% da receita do produto A com serviços em
mobile (oportunidade).
 Atender aos requisitos de negócio é o que satisfaz ao
cliente;
 Quando se conhece os reais requisitos de negócio, há

mais liberdade para se imaginar possíveis soluções
para o problema;
 Os requisitos de negócio ajudam a priorizar os

projetos;
 Os requisitos de negócio norteiam toda a Engenharia
de Requisitos
 Eles são o ponto de partida do trabalho do analista de
requisitos;
 Ajudam a perceber qualquer desvio de escopo durante o
levantamento e análise dos requisitos;
 Todos os requisitos da solução devem estar

relacionados pelo menos a um dos requisitos de
negócio.
 Quando são elaborados?
 Em atividades de análise de negócio, anteriores à criação
do projeto: pré-projeto, anteprojeto, estudo de
viabilidade, etc.
 Papel do analista de requisitos

 Refinar os requisitos, identificando questões que
permitam melhor compreensão das intenções iniciais.
 Onde ficam registrados?
 Casos de negócio (business case).
 Estudos de viabilidade.
 Anteprojetos.
 Termos de abertura de projetos.
 A partir desses documentos normalmente o analista
elabora um documento de visão.

Restrições
 Qualquer limitação às possíveis soluções de software
em desenvolvimento;
 Se não identificada a tempo pode causar desperdício

de tempo e recursos;
Restrição de Negócio
 Recursos orçamentários ou de tempo
 Disponibilidade dos envolvidos no projeto
 Restrições baseadas nas habilidades da equipe de

projeto e das partes interessadas
 Outras restrições organizacionais

Restrição Técnica
 Linguagem de programação;
 Plataforma e produtos específicos de software e
hardware;
 Tamanho de mensagens;
 Espaço ocupado pelos componentes de software da
solução;
 Número máximo e espaço ocupado pelos arquivos de
dados;
 Limitações quanto ao uso de processador e memória.
Premissas
 Suposições, informações que se acreditam como
verdadeiras, mas que ainda não foram confirmadas.
 Caso as premissas não se confirmem, riscos irão se

materializar.
Premissas
 Exemplos de premissas
 Previsão de recebimento de serviço necessário ao
sistema em desenvolvimento;
 Os usuários são fluentes no idioma inglês e têm acesso à

banda larga;
 Acesso às transações do software é apenas via Mozilla;
 Todos os clientes possuem CPF.

Requisitos das partes interessadas
 Partes interessadas são indivíduos que podem
 Afetar a solução de alguma forma;
 Ser afetado de alguma forma por ela.
 São os stakeholders.
 Descrevem necessidades e como será a interação de

uma parte interessada com a solução
 Registrados em memórias de levantamento, em geral de
forma não estruturada (gravações, atas, notas, etc.)
Requisitos das partes interessadas
 Produto do trabalho de Elicitação de Requisitos
 Ponte entre os requisitos de negócio e os da solução
 No conjunto desses requisitos pode ocorrer

 Requisitos similares (podem ser unificados)
 Requisitos conflitantes (devem ser resolvidos)
 Matéria prima para a Análise de Requisitos

Requisitos da solução
 Os requisitos das partes interessadas:
 Contêm conflitos a resolver;
 Contêm lacunas de informação;
 Contêm oportunidades de racionalização;
 Representam informações não estruturadas;
 O produto do trabalho para resolver esses problemas

são os requisitos da solução.
Requisitos da solução
 Esses requisitos são:
 Materializados em uma especificação de requisitos.
 Produto do trabalho da análise de requisitos.

Requisitos de transição
 Necessários para a transição da solução atual para a
nova solução entrar em operação
 Diferem dos demais tipos de requisitos, pois são

relevantes apenas durante o período de transição da
solução atual para a nova.
 São descartados após o projeto, têm caráter

temporário.
Requisitos de transição
 Exemplos:
 Os dados de contrato deverão ser migrados do sistema legado
para o novo sistema.
 No primeiro mês de operação da nova solução em produção, a
solução atual continuará funcionando em paralelo, sendo
descontinuada a partir desse período.
 A identificação desses requisitos deve ser precedida da
avaliação de dois cenários:
 Cenário-alvo, necessário à nova solução em funcionamento
(to-be);
 Cenário atual, indicando a situação atual como está (as-is).
Requisitos de software
 São compostos pelos requisitos da solução (o produto a
ser entregue) e pelos requisitos da transição (se
houver).
 Ambos são compostos por requisitos funcionais e
requisitos não funcionais.
Fonte: FATTO, 2017


 Requisitos de software são mantidos em diversos
artefatos, que variam conforme a metodologia de
desenvolvimento usada:
 Documento de visão
 Lista de requisitos
 História de usuário
 Caso de uso
 Modelos
 Requisitos de software são mantidos em diversos
artefatos, que variam conforme a metodologia de
desenvolvimento usada:
 Layout de telas e relatórios
 Especificação funcional
 Especificação complementar
 Glossário
Requisitos funcionais
 Descrevem o quê o software deve fazer em termos das
tarefas ou serviços do usuário, sem abordar sua
implementação.
 Descrevem a funcionalidade ou os serviços que se espera

que o sistema forneça;
 A especificação de requisitos funcionais de um sistema
deve ser completa e consistentes;
 Completeza. Todas as funções requeridas pelo usuário

devem estar definidas.
 Consistência. Os requisitos não devem ter definições

contraditórias.
 Na prática, para sistemas complexos e grandes, é quase
impossível atingir a consistência e completeza dos
requisitos.
 Fatores que contribuem pra isso:
 complexidade inerente ao sistema
 diferentes pontos de vistas.

 Exemplos:
 O sistema deve efetuar a gestão dos cursos.
 O sistema deve emitir o certificado de participação do
aluno no curso.
 O sistema deve garantir que somente alunos com
frequência superior a 75% possam emitir certificado.
 É possível verificar que os requisitos funcionais do

exemplo possuem diferentes níveis de objetivo (ou
granularidade).
Nível de granularidade
 Maior ou menor
abrangência na descrição
do comportamento
esperado para o software
em uma especificação
funcional.
 Requisitos funcionais com objetivo de usuário
 Estão no nível de uma única tarefa sob responsabilidade

de um único indivíduo em um momento que tem tudo o
que precisa no tempo para que a tarefa seja feita.
 Ao final da tarefa, o usuário cumpre seu objetivo, fica

satisfeito, não há nada mais a se fazer.
 Exemplo de requisitos com objetivo de usuário
 Efetuar baixa de título na relação de contas a receber.
 Emitir carta de renovação de contrato.
 Emitir certificado de participação do aluno no curso.
Fonte: Adaptado de VAZQUEZ E SIMÕES, 2016

 Requisitos funcionais com objetivo agregador
 Agregam vários objetivos de usuários em uma
especificação de alto nível;
 Referem-se a objetivos mais gerais e estão em um nível

de abrangência como foco em processos de negócio
de alto nível;
 Resumem um conjunto de tarefas de um ou mais

usuários.
 Exemplo de requisitos agregadores:
 Controlar fluxo de caixa.
 Gerir relacionamento com clientes.
 Efetuar gestão dos cursos.
Fonte: Adaptado de VAZQUEZ E SIMÕES, 2016

 Requisitos funcionais com objetivo agregador
 Em momentos preliminares, talvez boa parte dos

requisitos funcionais identificados esteja nesse nível
de objetivo;
 Alguns requisitos funcionais neste nível possuem um

comportamento tão padronizado que dispensam o
detalhamento, por exemplo:
 Requisitos associados à manutenção cadastral - CRUD
(Create, Read, Update, Delete).
 Requisitos funcionais com objetivo de subfunção
 Análogo aos objetivos agregadores, porém em sentido

inverso, há requisitos descritos em um nível inferior ao
dos objetivos do usuário: são passos e regras.
 Isoladamente não atendem a um objetivo do usuário.

 Os passos descrevem a troca de dados em ambas as
direções entre o usuário e o software; e entre o software e
os requisitos de armazenamento.
 Ex.: Validar cartão e senha de um cliente durante uma
transação bancária.
 As regras estão ligadas a leis que regem o negócio e
descrevem de forma complementar o funcionamento de
seus processos.
 Ex.: Limitar cada saque a um máximo de R$ 1000,00.
Fonte: FATTO, 2017

 Por que nível de granularidade?
 A evolução natural dos requisitos é caminhar de

objetivos mais gerais para mais específicos e com maior
detalhamento;
 Na especificação de requisitos é improvável que se tenha

todos os RF’s especificados no mesmo nível de
granularidade;
 Por que nível de granularidade?
 Perceber o nível de granularidade ajuda ao analista

encontrar o detalhamento adequado para a especificação
de requisitos;
 Detalhar além do necessário é desperdício de tempo;
 Detalhar menos que o necessário impede decisões

apropriadas sobre o escopo
 Se o objetivos for obter uma visão ampla do escopo (e
não necessariamente ainda detalhada). Ex.:
documento de visão, product backlog
 O RF especificado no nível de objetivo agregador é o

mais indicado;
 RF’s mais detalhados podem estar presentes, mas

limitados somente aos mais críticos e relevantes para a
necessária compreensão do escopo pelas partes
interessadas.
 Se o objetivos for obter uma visão profunda do escopo
(em parte ou todo). Ex.: especificação de casos de uso,
splitting de historias de usuário
 O RF especificado no nível de objetivo de usuário é o
mais indicado;
 RF no nível agregador significa trabalho de
levantamento pendente;
 RF no nível de subfunção é interessante para ajudar na
qualidade da especificação (facilidade de mudanças,
consistência, clareza).
Requisitos não funcionais
 Descrevem limitações de ordem geral aos requisitos
funcionais, complementando a especificação do
software.
 São restrições sobre as funções ou os serviços

oferecidos pelo sistema.
 Ex.: restrições de tempo, restrições sobre o processo de

desenvolvimento, padrões, etc.
 São aqueles que não dizem respeito diretamente
às funções específicas fornecidas pelo sistema;
 Podem estar relacionados a propriedades de

sistema como tempo de resposta e espaço em
disco;
 Muitos dizem respeito ao sistema como um todo, e

não a características individuais do sistema;
 Os requisitos não funcionais indicam restrições de
ordem geral relacionados:
 Ao Ambiente. Ex.: interoperabilidade, segurança,
privacidade, sigilo, etc.
 À organização. Ex.: locais para operação, aderência a

padrões, etc.
À implementação. Ex.: plataforma de software,

hardware, linguagem de programação, etc.
 Os requisitos não funcionais indicam restrições de
ordem geral relacionados:
 À qualidade. Ex.: facilidade de uso, confiabilidade,

eficiência, portabilidade, facilidade de manutenção, etc.
 Requisitos não funcionais devem ser expressos

quantitativamente, utilizando métricas que possam ser
objetivamente testadas;
 Requisito não funcional versus restrição técnica
 Padrões de classificação de requisitos não funcionais
 FURPS+. Padrão bastante simples denominado pelo

acrônimo FURPS+.
 ISSO/IEC 25010. Padrão mais abrangente. Define 31

subcategorias distribuídas em 8 categorias.
 FURPS+
 Funcionality (funcionalidade): enfoca os requisitos
funcionais.
 Usability (usabilidade): facilidade do uso, incluindo
fatores humanos, estética, interface do usuário,
materiais de treinamento, etc.
 Reliability (confiabilidade): integridade,
conformidade e interoperabilidade.
 Performance (desempenho): velocidade, eficiência,
taxa de transferência, tempo de resposta, etc.
 FURPS+
 Supportability (suportabilidade): extensibilidade,
adaptabilidade, manutenibilidade, compatibilidade,
configurabilidade, testabilidade, etc.
 + refere-se a
 Restrições de projeto.
 Restrições de implementação.
 Restrições de interface.
 Restrições física.
 ISO/IEC 25010 (Substitui a ISO/IEC 9126)
 Adequação funcional: grau em que as funcionalidades

atendem as necessidades especificadas e implícitas
quando utilizado em determinadas condições.
 Eficiência no desempenho: desempenho relativo à

quantidade de recursos usados em determinadas
condições.
 Compatibilidade: grau no qual um produto, sistema ou

componente pode trocar informações com outros
produtos, sistemas ou componentes.
 Usabilidade: grau no qual um produto ou sistema pode

ser usado por determinados usuários para alcançar
determinados objetivos de maneira efetiva, eficiente e
satisfatória em determinado contexto de uso.
 Confiabilidade: grau no qual um sistema, produto ou

componente executa determinadas funções em
determinadas condições por um determinado período
de tempo.
 Capacidade de manutenção: grau de efetividade e

eficiência com o qual um produto ou sistema pode ser
modificado por aqueles com essa intenção.
 Segurança: grau no qual um produto ou sistema
protege informações e dados de tal forma que as pessoas
ou sistemas tenham grau de acesso apropriado aos seus
perfis e níveis de autorização.
 Portabilidade: grau de efetividade e eficiência com o

qual um sistema, produto ou componente pode ser
transferido de um equipamento, software ou de um
ambiente operacional para outro.
 SOMMERVILLE (2011) apresenta a seguinte classificação:
 Exemplos de SOMMERVILLE (2011)
 Requisito de produto
 O MHC-PMS deve estar disponível para todas as clínicas durante
as horas normais de trabalho (segunda a sexta-feira, 8h30 às
17h30). Períodos de não operação dentro do horário normal de
trabalho não podem exceder cinco segundos em um dia.
 Requisito organizacional
 Usuários do sistema MHC-PMS devem se autenticar com seus
cartões de identificação da autoridade da saúde.
 Requisito externo
 O sistema deve implementar as disposições de privacidade dos
pacientes, tal como estabelecido no HStan-03-2006-priv.
 Métricas para especificar RNF - exemplos
FONTE: SOMMERVILLE (2011)

Requisitos inversos
 Indica o que o sistema ou projeto não irá fazer ou
entregar;
 Ajuda a gerenciar as expectativas das partes

interessadas, evitando criar expectativas irreais e
possíveis reclamações futuras;
 Dever ser usado com parcimônia. A prioridade é

declarar explicitamente o que a aplicação faz.
Resumindo...
 Os tipos de requisitos abordados pela ER
Referências
 CATHO. Cargo de Analista de Requisitos. Disponível em
http://www.catho.com.br/profissoes/analista-de-requisitos. Acesso: 30 mai 2017.
 FATTO. FATTO Consultoria e Sistemas. Disponível em

http://fattocs.com/pt/recursos/apresentacoes.html. Acesso: 11 abr 2017.
 POHL, Klaus; RUPP, Chris. Requirements Engineering Fundamentals: A Study Guide for
the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB
compliant. ISBN: 978-1-937538-77-4. 2 ed. Rockynook, 2015.
 SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison

Wesley, 2003.
 VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de Requisitos:

software orientado ao negócio. Rio de Janeiro: Brasport, 2016.

Slides Aulas Parte1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Slides Aulas Parte1

Uploaded by

Copyright:

Available Formats

Prof.

 Compreender a natureza do problema pode ser

 Como estabelecer exatamente o que o sistema deve

Fonte: FATTO, 2017

 Seria uma apropriação do prestígio da engenharia para

Fonte: "engenharia", in Dicionário Priberam da Língua Portuguesa [on line], 2008-2013,

 “a palavra engenharia traz os conceitos de criação,

Fonte: VAZQUEZ E SIMÕES, 2016

Fonte: VAZQUEZ E SIMÕES, 2016

 A Engenharia de Requisitos está completamente

 “(1) a aplicação sistemática de conhecimento tecnológico

 “(2) a aplicação de uma abordagem sistemática,

1 - International Organization for Standardization (Organização Internacional de Normalização)

 O conhecimento e as habilidades relativas às tarefas da

 Existem modelos de referência:

 SWEBOOK (Software Engineering Body of Knowledge)

 Áreas de processo do CMMI (Capability Maturity Model

 Gerência de configuração e mudança

Fonte: FATTO, 2017

 Duas áreas abordam a ER:

 Gestão de requisitos (REQM – Requirements

Fonte: VAZQUEZ E SIMÕES, 2016

 É comum, principalmente em organizações públicas e

 Nas exigências e expectativas do mundo atual, torna-se

 Na prática, acaba-se trabalhando muito próximo à

Fonte: VAZQUEZ E SIMÕES, 2016

 Extreme Programming (XP);

 Maior ênfase inicialmente no entendimento dos

 Explorar a abrangência do produto, especificando as

 As atividades da ER são intercaladas gradualmente na

 Ciclos curtos de desenvolvimento (2 a 4 semanas).

Fonte: VAZQUEZ E SIMÕES, 2016

Fonte: FATTO, 2017

Fonte: VAZQUEZ E SIMÕES, 2016

 A ER facilita a interação com o cliente na

 Têm inicio com o entendimento da necessidade do

 Passam pelo acordo sobre a solução que será construída.

 “realiza o levantamento de requisitos e especificação de

 35% têm pós-graduação;

 37% têm graduação em Sistemas de Informação;

 Levaram 1 ano e 11 meses até chegar a esse cargo (a partir

 56% têm inglês intermediário.

 Papel Central. O Engenheiro de Requisitos

1. Pensamento analítico. Habilidade para se

2. Empatia. Boa intuição e empatia são úteis na

3. Habilidades de comunicação. Par obter os requisitos

4. Habilidades para resolver conflitos. Diferentes

5. Habilidades de moderação. Deve ser hábil para fazer a

6. Autoconfiança. Sendo frequentemente o centro da

7. Persuasão. Deve ser capaz de representar os requisitos

 A documentação é necessária para que a

 (1) Uma condição ou capacidade necessária por um

 (2) Uma condição ou capacidade que deve ser atingida

4. Uma condição ou capacidade que deve ser alcançada

 A definição (4) consolida, clarifica e complementa as

 Permitir que a equipe de desenvolvimento compreenda

 Lista de requisitos funcionais

 Lista de requisitos não funcionais

 Especificação detalhada de requisitos

 Desafio: construir uma visão de especificação que seja

 Documento de requisitos orientado ao cliente é útil

 Detalhar demais: elemento paralisante do projeto.

 Desafio: encontrar o equilíbrio do nível de detalhe.