07/10/2015

Engenharia de
Requisitos

Prof. Luiz Camolesi Jr.

1
 07/10/2015

Processo de Engenharia de
Requisitos
Extração e
Estudo de
Análise de
Viabilidade
Requisitos Espedificaçã
o Requisitos
Validação
Requisitos

Relatório Modelos de
Viabilidade Sistema
Requisitos de
Usuário e de
Sistema
Especificação
de Requisitos
de Software

2
 07/10/2015

Estudo de Viabilidade

Passo a Passo
Contextualização do sistema
Descrição do problema
Soluções Possíveis (pesquisa sistemas semelhantes, idéias novas)
Viabilidade Operacional (fontes informação, desempenho, economia, controle,
eficiência, serviços, nível de satisfação do cliente)

Viabilidade Técnica
Viabilidade Econômica (investimentos)
Viabilidade de Cronograma

3
 07/10/2015

Estudo de Viabilidade
Questionamentos:
O sistema contribui para os objetivos gerais da organização?
O sistema pode ser implementado com a utilização de tecnologia atual
dentro das restrições de custo e de prazo?
O sistema pode ser integrado com outros sistemas já em operação?
Verificação:
Como a organização se comportaria, se esse sistema não fosse
implementado?
Quais são os problemas com os processos atuais e como o sistema
ajudaria a diminuí-los?
Quais serão as contribuições diretas advindas do novo sistema?
Essas informações podem ser transferidas para outros sistemas existentes
na organização e/ou podem ser recebidas de programas já
implementados?
O sistema requer tecnologia que não tenha sido utilizada anteriormente
na organização?
Quais as compatibilidades que serão necessárias para
4 com o sistema?
 07/10/2015

Processo de Engenharia de
Requisitos
Extração e
Estudo de
Análise de
Viabilidade
Requisitos Espedificaçã
o Requisitos
Validação
Requisitos

Relatório Modelos de
Viabilidade Sistema
Requisitos de
Usuário e de
Sistema
Especificação
de Requisitos
de Software

5
 07/10/2015

Processo de Engenharia de Requisitos:

(Kotonya e Sommerville, 1998; SWEBOK)
modelo em espiral
 07/10/2015

Classificação de Requisitos
 07/10/2015

Processo de Engenharia de
Requisitos: modelo de
documento
atividades de alto nível
identificação de
requisitos
de requisitos

análise e
negociação
de requisitos

especificação,
documentação
de requisitos
validação de
requisitos

necessidades dos usuários,

sistemas legados,
informação do domínio,
normas organizacionais,
etc.
8
07/1
0/20
 07/10/2015

Atividades do Processo de
Extração de Requisitos

9
07/1
0/20
 07/10/2015

Designações Equivalentes

elicitação de requisitos
descoberta de requisitos
identificação de requisitos
captura de requisitos
aquisição de requisitos
levantamento de requisitos

07/1 10
0/20
15
 07/10/2015

Dimensões da Elicitação de Requisitos

conhecimento geral do
domínio

compreender o
domínio de
aplicação
compreender o estende e especializa
conhecimento geral do
compreender as problema a domínio
necessidades e ser resolvido
restrições dos
interessados compreender o
contexto de
que atividades devem ser negócio
suportadas pelo sistema?
qual o papel de sistemas
existentes? etc. como é que o sistema contribui para os
objetivos do negócio? etc.

Kotonya, 1998
 07/10/2015

Especificação de Requisitos
acordo entre o cliente e o desenvolvedor do sistema
propósito básico da especificação é criar uma ponte de comunicação
entre os diversos tipos de pessoas envolvidas no desenvolvimento de
sistemas de software
tipos de especificação:
informais
formais Quanto à formalidade
semi-formais
operacionais
Quanto à maneira de representação
descritivas
 07/10/2015

Estágios do Processo

Estabelecimento de objetivos
Objetivos gerais do negócio, descrição genérica do problema a
resolver, necessidade do sistema e restrições sobre o sistema.
Aquisição de conhecimento de background
informação sobre a organização em que o sistema vai ser
instalado, o domínio de aplicação do sistema e informação
sobre sistemas existentes
Organização do conhecimento
Organizar a grande quantidade de conhecimento (informação?)
recolhida no estágio anterior.
Recolher requisitos dos stakeholders
Consultar os interessados no sistema para descobrir os seus
requisitos.
 07/10/2015

Fontes de Requisitos (1)

(fonte: SWEBOK)

Objetivos gerais de alto nível do sistema

objetivos gerais de alto nível do sistema, problema que o sistema
deve resolver, motivação para a implementação do sistema, fatores
críticos de sucesso, interesse para o negócio, ...
necessário avaliar custos e benefícios de atingir os objetivos, por
exemplo com estudo de viabilidade
Conhecimento do domínio de aplicação
necessário para inferir conhecimento tácito que os stakeholders não
explicitam, avaliar trade-offs entre requisitos conflitantes, etc.
pode ser obtido junto de especialistas do domínio, documentos, etc.
Stakeholders do sistema
fundamental identificar, representar e gerir os pontos de vista,
interesses e necessidades de todos os interessados no sistema
(usuários, clientes, etc.)
 07/10/2015

Fontes de Requisitos (2)

(fonte: SWEBOK)

ambiente operacional
o ambiente operacional em que o sistema vai executar pode impor
diversos requisitos
aproveitamento de infra-estruturas físicas e lógicas existentes
interoperabilidade com sistemas existentes (internos ou
externos) etc.
ambiente organizacional
muitos sistemas destinam-se a suportar processos de negócio,
devendo-se adequar à estrutura, cultura, políticas, regras e
normas internas da organização (intra/inter)
ambiente externo
normas, regulamentos, legislação, etc.
podem impor requisitos
exemplos: lei de protecção de dados pessoais, normas de
acessibilidade, ... 07/1 15
0/20
15
 07/10/2015

Produtos e Sistemas existentes como

Fontes de Requisitos

produtos de mercado
produtos concorrentes
quando se desenvolve um produto para um mercado, é necessário
posicioná-lo e diferenciá-lo em relação aos produtos existentes
por vezes compatibilidade com produtos concorrentes é uma
vantagem
por vezes pretende-se copiar as funcionalidades de um produto
existente (exemplo: open office)
soluções candidatas
quando se pretende adquirir um produto de mercado, é conveniente
formular os requisitos em termos que facilitem a análise de
adequação das soluções existentes no mercado
sistemas e produtos internos
interoperabilidade com sistemas existentes
substituição ou evolução de sistemas existentes
 07/10/2015

Técnicas de Elicitação de
Requisitos
análise de documentação
análise de sistemas existentes
entrevistas
encontros facilitados (workshops, brainstorming)
JAD (Joint Application Design )
cenários
protótipos
reutilização de requisitos
questionários
pontos de vista
 07/10/2015

Etapas Básicas (todas as

técnicas)
Perguntar
Observar e Inferir
Discutir e Formular
Negociar (a partir de um conj padrão)
Estudar e Identificar Problemas
Descobrir (processos criativos)
 07/10/2015

Análise de Documentação

sobre o domínio da aplicação

sobre dados essenciais
sobre o organização
sobre a legislação
sobre sistemas existentes
...
 07/10/2015

Análise de Sistemas
Existentes
sistemas existentes sempre são fontes de requisitos
Interface
Dados de entrada
Resultados
Etc….
 07/10/2015

Entrevistas
entrevistar os futuros usuários e outros stakeholders é a
técnica mais vulgar e simples de obter informação para
identificar requisitos
 07/10/2015

Entrevistas

a entrevista é uma técnica simples, mas não é fácil de aplicar

enviesamento do entrevistador (não escuta)
predisposição do entrevistado
relação pessoal
 07/10/2015

Entrevistas - Fases

Identificação dos Candidatos

Preparação
Condução da Entrevista
Conclusão
 07/10/2015

Entrevistas – Identificação Candidatos

financiador do projeto / gerente ou executivo

cada candidato é fonte de informação para novos candidatos
Com quem mais eu deveria conversar?
Quem mais pode usar o sistema?
Quem concordaria com você nessa questão?
Quem discordaria de você nessa questão?
Quem mais interage com você?
 07/10/2015

Entrevistas – Papéis

Líder da entrevista (faz os questionamentos)

Comprador
Usuários
Engenheiros (requisitos, analistas, arquitetos)
Escrivão (ã) (anota questões e respostas)
Secretário (a) (agendamentos e preparação)
 07/10/2015

Entrevistas – Preparação

Agendar entrevistas com os candidatos

Feito com antecedência
Esclarecido o objetivo e duração da entrevista
Relembrar o entrevistado um dia antes
Preparar lista de questões
Feito com antecedência
Manter ordem lógica e agrupadas por assunto
Entregue ao candidato
 07/10/2015

Entrevistas – Condução

Protocolo
Apresentação dos participantes
Revisão dos objetivos da entrevista
Explicar notações (por ex. UML)
Resumir, refrasear e mostrar implicações
Manter o processo visível (estamos indo bem?)
Tipos de Questões (Caráter Geral, Específicas)
Coloque questões no contexto
Verifique se há erros e corrija-os
Finalize a entrevista (sumarizar e consolidar, explique
próximas ações, agradeça ao entrevistado)
 07/10/2015

Entrevistas – Atividades Subsequentes

Protocolo
Enviar ao entrevistado um agradecimento por escrito
Produzir um resumo escrito
Confirme as informações com fontes confiáveis
Revise os procedimentos da entrevista para melhorias do processo para futuras
entrevistas
 07/10/2015

Brainstorming

Brainstorming é uma técnica para a geração de novas idéias por um conjuto

de pessoas (4 a 10)
encoraja a participação de todos
permite o aproveitamento e refinamento de outras ideias
pode ser bastante produtiva (nº de ideias/hora)
o resultado pode ser um conjunto de soluções
encoraja o pensamento livre... (maluquices...)
pode revelar diferentes visões do problema
ajuda a sanar limitações cognitivas
 07/10/2015

Brainstorming

regras do brainstorming

não permitir críticas ou debates

deixar a imaginação voar...
gerar tantas ideias quanto for possível
mudar e combinar idéias
 07/10/2015

Brainstorming – Papéis

Líder (facilitador)
Compradores
Usuários
Engenheiros (requisitos, analistas, arquitetos)
Escrivão (ã) (anota idéias, prepara especificação)
Secretário (a)(agendamentos, preparação)
 07/10/2015

Brainstorming – Preparação

Identificar os participantes (usuários, compradores, engenheiros)

Designar o líder
Agendar a sessão com os participantes
Relembrá-los sobre a sessão um dia antes
Preparar a sala da sessão (papel, canetas coloridas, transparências, fita
colante, flip chart, etc…)
 07/10/2015

Brainstorming - Sessão

Incentivar a geração de idéias (sem censura)

explicar as regras e objetivos (líder)
gerar e documentar ideias (escrivão)
deixar idéias visíveis
identificar os diferentes pontos de vista, os serviços do sistema, as entradas
de dados, os requisitos não funcionais, os eventos de controle e as exceções
pode ser auxiliada por vídeo-conferência
 07/10/2015

Brainstorming - Consolidação

cortar idéias irrelevantes

agrupar idéias de mesmo contexto
refrasear idéias
definir as características de cada idéia
estabelecer prioridades (essenciais, boas, não essenciais, más)
especificação das idéias remanescentes
 07/10/2015

Workshops

um workshop de requisitos é uma técnica de grupo para o debate e acordo

das questões asociadas à identificação dos requisitos
É feita através da formação de um grupo de representantes dos stakeholders
facilitada por alguém com competência para conduzir o processo de
identificação e análise de requisitos
 07/10/2015

Workshops

Preparação
"vender" o conceito
assegurar a participação dos stakeholders adequados
garantir os aspectos logísticos
fornecer materiais para discussão antecipadamente
escolher o facilitador
estabelecer uma agenda
 07/10/2015

Workshops

Condução

"soltem os cães"...
brainstorming
produção de documentos e continuação
 07/10/2015

Workshops

Consolidação

Resumir
Relatar
Validar
 07/10/2015

JAD –Joint Application Design

técnica para promover cooperação, entendimento e trabalho em grupo entre

compradores, usuários e desenvolvedores
desenvolvedores ajudam os usuários a formular problemas e explorar soluções
e os usuários ganham um sentimento de envolvimento e responsabilidade
para com o sucesso do sistema
desenvolvida pela IBM em 1977
 07/10/2015

JAD – Características

dinâmica de grupo, com a utilização de sessões de grupo facilitadas para

aumentar a capacidade dos indivíduos
uso de técnicas visuais para aumentar a comunicação e o entendimento
manutenção do processo organizado e racional
filosofia “what you see is what you get”, utilizando documentação padrão
que é preenchida e assinada por todos os participantes de uma sessão
 07/10/2015

JAD – Papéis

Líder ( facilitador, estima fontes de requisitos, planeja e acompanha o

processo)
Analista (produção de documentos de saída das sessões, habilidade com
ferramentas)
Executar (gerente responsável pelo produto, dá a visão estratégica do sistema
e toma decisões executivas)
Representantes dos Usuários (vários perfis)
Representantes de Sistemas de Informação
Especialista (conhece tópico específico)
 07/10/2015

JAD – Passos e Fases

Dois passos principais:

Planejamento (extração e especificação requisitos)
Projeto (projeto do software)
Fases
Adaptação
Sessão
Finalização
 07/10/2015

Planejamento JAD – Adaptação

Conduzir a orientação (entender o que já se sabe, que tipo de sistema está

sendo construido, decisões já tomadas, exige conhecimento organizacional)
Organizar o grupo (líder seleciona os participantes, verifica se todos foram
convidados, entrega antecipada da lista de perguntas)
Ajustar o processo (líder define tempo e quantidade das sessões, formato
geral dos documentos)
Preparar o material (líder faz arranjos logísticos)
 07/10/2015

Projeto JAD – Adaptação

Identificar e estimar projetos (líder conduz a sessão de estimativa de

recursos)
Identificar participantes para o projeto
Agendar encontros de projeto
 07/10/2015

Planejamento JAD – Sessão

Conduzir a orientação (líder dá boas vindas e as apresentações são feitas, dá

visão geral sobre o processo JAD, dá visão detalhada sobre tarefas, executor
resume o esforço já feito )
Definir Requisitos de Alto Nível (objetivos, benefícios, estratégias, restrições,
segurança e controle)
Registro dos requisitos (analista anota em lousas ou locais bem visíveis por
todos)
 07/10/2015

Projeto JAD – Sessão

Documentar questões e informações ambígüas ou em aberto

Atribuir as questões levantadas aos participantes para que sejam resolvidas
 07/10/2015

Planejamento JAD – Consolidação

Delimitar o escopo do sistema (organizar os requisitos e acordar sobre o

escopo do sistema)
recursos audiovisuais são importantes nesta fase
tarefas podem ser anotadas sobre dispositivos magnéticos
setas podem ligar tarefas representando fluxos de dados
 07/10/2015

Projeto JAD – Consolidação

Líder revisa a informação coletada e decisões tomadas

Participantes se manifestam quanto às observações do líder
 07/10/2015

JAD – Finalização

transformar as transparências, anotações da lousa de papel e outros

documentos escritos à mão na fase da sessão, em documentos de
planejamento formais, incluindo a especificação dos requisitos de software
Etapas:
Completar o documento
Revisar o documento
Obter a aprovação do executor
 07/10/2015

Prototipagem

Protótipo é uma versão inicial de um sistema usada para apoiar

essencialmente as fases de identificação, análise e validação de
requisitos
Tipos de protótipos:
“Remendado” (interação e ineficiência)
Escalar não operante (útil para testar alguns aspectos específicos – por ex.
E/S)
Escalar completo (sistema piloto)
Características essenciais (algumas opções do menu)
 07/10/2015

Prototipagem

Características
desenvolvimento rápido
funcionalidades limitadas
requisitos não funcionais pouco considerados
várias tecnologias
pode ir desde maquetes a protótipos evolutivos
 07/10/2015

Prototipagem: benefícios

benefício principal
os clientes e usuários finais têm contato com um sistema realista cedo o que lhes
permite compreender melhor os requisitos que pretendem identificar e analisar
outros benefícios
ajuda a estabelecer a viabilidade e utilidade do sistema
é a única forma efetiva de desenvolver IHC
pode ser usado na validação
o estudo cuidadoso dos requisitos ajuda a revelar inconsistências e lacunas
 07/10/2015

Prototipagem: custos

a decisão de usar a prototipagem deve ser tomada com recurso a uma

análise custo-benefício

custos envolvidos na prototipagem

formação, desenvolvimento, prazos mais alargados, protótipos incompletos
 07/10/2015

Pontos de Vista
 07/10/2015

Tipos de Pontos de Vista

Pontos de vista de interação

Coleta requisitos de pessoas e outros
sistemas que interagem diretamente com o
sistema que está sendo desenvolvido
Pontos de vista indiretos
Stakeholders que não interagem
diretamente mas impactam o sistema
Pontos de vista do domínio
Restrições de domínio que impactam o
sistema (legislação , padrões)
 07/10/2015

PIECES

Apropriado para análise de sistemas

existentes e que deverão ser reformulados

A técnica pode também ser adaptada para

domínios de aplicação específicos

Ajuda a lidar com problemas de articulação e

barreiras de comunicação.
 07/10/2015

PIECES

Categorias
Performance (desempenho)
Information and Data (informação e dados)
Economy (economia)
Control (controle)
Efficiency (eficiência)
Services (serviços).
 07/10/2015

PIECES

Desempenho
Medidas
Throughput (número de tarefas
completadas em uma unidade de tempo)
Número de ordens processadas no
dia
Tempo de Resposta (quantidade de
tempo necessária para executar uma
única tarefa)
Perguntas devem revelar estes aspectos
 07/10/2015

PIECES

Informação e Dados
Informação deve ser apresentada na
medida certa
Falta de informação ou informação errada
invalida o sistema
Excesso de informação ou apresentação
inadequada causa frustração
Perguntas devem direcionar a escolha
 07/10/2015

PIECES

Economia
Custo de usar um processo ou sistema
Nível de serviço
Capacidade para lidar com alta demanda
Perguntas devem identificar horários de
pico e fatores de estresse do sistema
 07/10/2015

PIECES

Controle
Desvio de desempenho deve ativar controle
para tomar ações
Interfaces de hardware apropriadas
Segurança
Controle de Acesso
Auditoria do Sistema
Perguntas devem identificar restrição de
acesso e interação do sistema
 07/10/2015

PIECES

Eficiência
Recursos úteis x Recursos gastos
Identificar redundâncias desnecessárias
Algoritmos e estruturas ineficientes
Interfaces com baixa usabilidade
Perguntas devem identificar estes fatores
 07/10/2015

PIECES

Serviços
Identificar serviços necessários
Identificar serviços essenciais
Interfaces para prover serviços para outros
sistemas
Interfaces com baixa usabilidade
Perguntas devem identificar estes serviços
 07/10/2015

Questionários

Aplicabilidade a domínios específicos

Perguntas precisam ser focadas

Útil para coletar dados de pessoas

fisicamente distantes ou de grupos numerosos
 07/10/2015

Questionários

Elaboração
Identificar o conjunto a inquirir
Agrupar títulos de assuntos de mesma
natureza
Estudar os objetivos
Entender as caracterísitcas do inquiridos
Definir as opções por tipo de perguntas
Definir como serão tabuladas as
respostas
 07/10/2015

Questionários

Tipos de Questões
Abertas (qualitativas)
Liberdade de respostas
Partir de questões gerais para
específicas
Fechadas (quantitativas)
Limita o inquirido a opções que
são focos da pesquisa
Podem ser gradativas
 07/10/2015

Cenários

abordagem para colocar os interessados num sistema perante uma

situação realista em que simulam ou apenas antevêem a sua interação
com o sistema

materializam-se em histórias que explicam como é que o sistema poderá ser

usado
 07/10/2015

Cenários: definição

mais definições
uma história ou exemplo de eventos retirados da experiência do mundo
real; incluem detalhes do contexto do sistema (cenas)
um caminho ou instância de um modelo (normalmente de casos de
utilização)
a visão futura de um sistema a ser desenhado, com sequências de
comportamento e descrições contextuais
 07/10/2015

Cenários: objetivos

identificar e clarificar requisitos

adicionar detalhe a requisitos mais gerais
compreender a relação entre requisitos

validar requisitos
compreender um requisito no seu contexto de utilização
verificar se a sua relação com outros requisitos faz sentido
 07/10/2015

Cenários: conteúdo

descrição do sistema antes de se entrar no cenário

ocorrem ao mesmo tempo

outras atividades que
informação sobre
fluxo normal de eventos

exceções ao
fluxo normal de eventos

descrição do estado do sistema depois de completado o cenário

 07/10/2015

Cenários: abordagem

Sutcliffe, 2002
 07/10/2015

Reutilização de requisitos

Envolve pegar nos requisitos que foram desenvolvidos para um

sistema e usá-los num sistema diferente
Uma definição mais abrangente:
"requirements reuse is the requirements engineering task
during which all or part of existing reusable requirements
work products are identified, evaluated for relevancy, and
where appropriate reused (possibly with modification)"
(in Open Process Framework, http://www.donald-firesmith.com)
Poupa tempo e esforço, pois os requisitos reutilizados já foram
analisados e validados noutros sistemas
É correntemente um processo informal, mas a reutilização
mais sistemática poderia conduzir a poupanças maiores
Grau de reutilização pode chegar a 50% (cf. Kotonya & Sommerville)
 07/10/2015

Possibilidades de
reutilização
requisitos que têm a ver com o domínio de
aplicação
exemplo no domínio da hotelaria: um quarto não pode
ser vendido a dois clientes diferentes para a mesma
data
podem ser requisitos comuns a uma família / linha de
produtos / aplicações / sistemas (ver a seguir)
requisitos que têm a ver com o estilo de
apresentação da informação
garantir consistência de estilo entre aplicações
requisitos que reflectem políticas da
organização, como por exemplo políticas de
segurança
exemplo: cifrar dados pessoais
 07/10/2015

referências e informação
adicional
Gerald Kotonya, Ian Sommerville,
Requirements Engineering – Processes and
Techniques, Wiley, 1998 (capítulo 3)
User Centerd Requirements Engineering:
Theory and Practice. Alistair Stutcliffe.
Springer. 2002.