Transcript Aula03 – Engenharia de Requisitos

ENGENHARIA DE SOFTWARE
Set/2010
Professor Mário Dantas
Aula 03 - Agenda

Engenharia de Requisitos
Objetivos



Conhecer os conceitos e técnicas relacionadas a
engenharia de requisitos, bem como sua aplicação;
Saber as diferenças entre os requisitos de software
funcionais e não funcionais;
Entender como os requisitos podem ser organizados em
um documento de requisitos.
Seu pior pesadelo

Um cliente entra no seu escritório, senta-se, olha você
direto nos olhos e diz:
“Eu sei que você pensa que entende o que eu disse, mas o que
você não entende é que, o que eu disse, não é o que eu queria
dizer.”
Definições



Pfleeger (2004), um requisito é uma característica do
sistema ou a descrição de algo que o sistema é capaz
de realizar para atingir os seus objetivos.
Sommerville (2007), as descrições das funções e
restrições são os requisitos do sistema.
SWEBOK (2004), um requisito é descrito como uma
propriedade que o software deve exibir para resolver
algum problema no mundo real.
Definições


Uma condição ou capacidade necessária para um
usuário resolver um problema ou alcançar um
objetivo.
Uma condição ou uma capacidade que deve ser
alcançada ou estar presente em um sistema para
satisfazer um contrato, padrão, especificação ou
outro documento formalmente imposto.
Importância dos Requisitos

Resultados de um estudo feito pelo Standish Group
em 350 companhias e 8000 projetos de software
(Pfleeger, 2004):
 31%
dos projetos cancelados antes de estarem
completos
 Em pequenas companhias, somente 16% dos projetos
foram entregues no prazo e no orçamento inicialmente
estabelecido
 Em grandes companhias, apenas 9% estão de acordo
com esses critérios
Importância dos Requisitos




O Standish Group classificou os projetos em 3
categorias:
Sucesso (16,2%) : Cobre todas as funcionalidades,
em tempo e dentro do custo previsto (cronograma e
orçamento)
Problemático (52,7%) : Não cobre todas as
funcionalidades exigidas, custo aumentado e/ou
com entregas em atraso.
Fracasso (31,1%): Cancelado durante o
desenvolvimento
Desafios



Compreensão do domínio do problema.
Comunicação efetiva com reais usuários e clientes
do sistema.
Evolução contínua dos requisitos do sistema.
Domínio


O termo, no contexto da engenharia de software, é
utilizado para denotar ou agrupar um conjunto de
sistemas ou de áreas funcionais, que exibem
características similares.
É definido por um conjunto de características que
descrevem uma família de problemas para os quais
uma determinada aplicação pretende dar solução.
Especificação de Requisitos



Estabelece uma base de concordância entre o
cliente e o fornecedor sobre o que o software fará.
Fornece uma referência para a validação do
produto final (uma especificação de requisitos de
alta qualidade é pré-requisito para um software
de alta qualidade).
Reduz o custo do software.
Por que precisamos de requisitos?
Para entender o que o
cliente quer
Para entender o problema
do negócio
Para documentar o que o
cliente quer
Para documentar o escopo
do projeto e definir suas
restrições
Para assegurar a
qualidade e a satisfação
do cliente
Para definir critérios de
aceitação e gerenciar as
expectativas do cliente
Definição

Sommerville (2003), Engenharia de Requisitos é o
processo de descobrir, analisar, documentar e
verificar as funções e restrições do sistema.
Engenharia de Requisitos
O processo de descobrir, analisar, documentar
e verificar as descrições dos serviços
fornecidos pelo sistema e as suas restrições
operacionais.
Engenharia de Requisitos
“Entender os requisitos de um problema está
entre as tarefas mais difíceis enfrentadas por um
engenheiro de software.” (Pressman, R.)
Engenharia de Requisitos


Descreve as atividades relacionadas à investigação
e definição de escopo de um sistema de software.
Processo sistemático de produção de requisitos por
meio de atividades cooperativas de análise em que
os resultados são documentados em uma variedade
de formatos e a precisão das observações é
constantemente verificada.
Questionamentos Típicos


Como seguir um processo pré-estabelecido se
tantos fatores são desconhecidos no início do
desenvolvimento do software?
Os fatores desconhecidos serão melhor elucidados
e os riscos serão minimizados com um processo
sistemático, iterativo e incremental.
Questionamentos Típicos


Quantas iterações são necessárias para verificar a
correção e a precisão das observações?
A quantidade de iterações ideal será aquela
suficiente para que cliente e fornecedor sintam-se
seguros e concordem com o que está definido,
mesmo com o que surgir de novo e for aceito para
o escopo do projeto.
Questionamentos Típicos


Quais representações e notações devem ser usadas
na captura e documentação dos requisitos?
As representações e notações devem estar previstas
no processo de software e no método adotado por
esse processo. Tipicamente, são usados casos de uso
e suas especificações .
Questionamentos Típicos


Qual o nível de precisão e formalidade dos
requisitos?
Dependerá de quão crítico é o sistema e das
características do cliente.
Questionamentos Típicos


Como sabemos que chegamos ao final do processo?
Similarmente à quantidade de iterações, até que
haja uma base sólida de concordância entre o
desenvolvedor e o cliente
Visão Geral
Engenharia de Requisitos
Produção de
Requisitos
Gerência de
Requisitos
Levantamento
Controle de Mudança
Registro
Gerência de
Configuração
Obtenção de
Comprometimento
Rastreabilidade
Verificação
Gerência de Qualidade
de Requisitos
Síntese dos Objetivos




Estabelecer uma visão comum entre o cliente e a
equipe de projeto sobre os requisitos que serão
atendidos;
Registrar e acompanhar requisitos ao longo de
todo o desenvolvimento;
Documentar e controlar os requisitos para
estabelecer uma base para uso gerencial e da
equipe de desenvolvimento;
Manter planos, artefatos e atividades de software
coerentes com os requisitos alocados.
Uma Última Questão

O que acontece se:
O
usuário mudar de idéia em relação a uma
funcionalidade?
 O ambiente mudar?
 O usuário perceber novas possibilidades na
automação?
 O engenheiro de requisitos (ou analista) não ter
entendido corretamente a necessidade do usuário?
Gerência de Mudança



É preciso gerenciar as mudanças!
Mudanças em requisitos ao longo do processo
fazem parte do desenvolvimento de software.
Alterações em requisitos podem implicar mudanças
em artefatos de projeto, de código, casos de testes,
etc.
Identificação dos Requisitos



Trata-se da identificação dos requisitos em si para
formação da idéia inicial do sistema e
compreensão do domínio do problema.
“Trabalhe com os usuários e não contra eles”
(AMBLER).
“Temos que aceitar a instabilidade dos requisitos
como um fato da vida, e não condená-la como o
resultado de um raciocínio mal conduzido” (COAD).
Ações com Foco no Usuário





Identificar Objetivos de Negócio (Por que
desenvolver algo?)
Identificar Stakeholders (Quem está envolvido?)
Obter diferentes Pontos de Vista (Com que os
stakeholders estão preocupados? Existem conflitos?)
Resolver Conflitos
Identificar Cenários (Quais resultados as pessoas
desejam? Sob que circunstâncias?)
Problemas Comuns



Escopo: O limite do sistema é mal definido, ou
detalhes técnicos desnecessários confundem os
objetivos globais
Entendimento: Os clientes e usuários não estão
completamente certos do que é necessário, não tem
pleno entendimento do domínio do problema, têm
dificuldade de comunicar as necessidades, têm
pouca compreensão das capacidades
Volatilidade: Os requisitos mudam com o tempo
Desafios a Suplantar


Falta de conhecimento do usuário das suas reais
necessidades e do que um produto de software
pode oferecer
Falta de conhecimento do desenvolvedor sobre o
domínio do problema
Habilidades do Desenvolvedor



Dominar o processo de produção de requisitos e
suas técnicas
Ouvir o que os usuários têm a dizer sem induzi-los
a aceitar visões e interpretações já vivenciadas
pela equipe
Comunicar adequadamente aos usuários e clientes
a evolução do trabalho e suas limitações
A produção de requisitos é um processo social
Classificação de Requisitos

Classificação Comum:
 Requisitos Funcionais
 Requisitos Não Funcionais
 Requisitos do Domínio
Outras Classificações para Requisitos



Requisito do usuário: declarações sobre as funções
que o sistema deve oferecer
Requisito do sistema: detalhamento das funções e
das restrições (contrato entre cliente e
desenvolvedor)
Requisito do projeto: define como o projeto deve
ser conduzido e que artefatos devem ser
produzidos (escopo do projeto).
Requisitos Funcionais



Requisitos diretamente ligados ao comportamento
do software
Descrevem as funções que o software deve
executar
Descrevem as interações entre o sistema e seu
ambiente
“O software deve permitir que o atendente consulte o relatório com os
resultados dos testes clínicos de um paciente”.
Exemplos



[RFO1] O software deve permitir que o atendente
efetue cadastro de clientes.
[RFO2] O software deve permitir que o caixa
efetue o registro de itens vendidos.
[RFO3] O software deve permitir que o
administrador gere o um relatório de vendas por
mês.
Exercícios




Escreva três requisitos funcionais para sistemas a
serem desenvolvidos para os seguintes domínios:
Vídeo Locadora
Apoio Inteligente à Análise de Risco para Bolsa de
Valores
Sistema de Caixa de Auto-atendimento de um
Sistema Bancário.
Uma Solução Possível

Vídeo Locadora:
O software deve permitir que o administrador efetue o
cadastro de clientes
 O software deve permitir que o administrador efetue o
cadastro de DVDs
 O software deve permitir que o atendente efetue o registro
de DVDs alocados


Auto-atendimento Bancário:
O software deve permitir que o cliente consulte seu extrato
 O software deve permitir que o cliente efetue saque;
 O software deve permitir que o cliente efetue o pagamento
da fatura do cartão de crédito.

Soluções Possíveis


Apoio Inteligente à Análise de Risco para Bolsa de
Valores
O domínio da aplicação pode dificultar – e muito –
o trabalho de produção dos requisitos!
Requisitos Não Funcionais



São requisitos que expressam condições que o
software deve atender ou qualidades específicas
que o software deve ter.
Em vez de informar o que o sistema fará, os
requisitos não funcionais impõem restrições ao
sistema.
Podem ser mais críticos que requisitos funcionais,
chegando a tornar um sistema impossível ou inútil.
Exemplos


“As consultas ao sistema devem ser respondidas
rapidamente”
“As consultas ao sistema devem ser respondidas em
menos de três segundos”
Requisitos Não Funcionais devem ser mensuráveis e
estar associados a uma forma de medida ou
referência
Medidas para Requisitos
Não Funcionais
Propriedade
Medida
Velocidade
Transações processadas por segundo
Tempo de resposta do usuário/evento
Tamanho
Kbytes
Num. De chips de RAM
Facilidade
Tempo de treinamento
Num. Quadros de ajuda
Confiabilidade
Tempo médio de falhas
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Robustez
Tempo de reinício após a falha
Percentual de eventos causando falha
Portabilidade
Num. de sistemas destino
Classificação dos RNF
Classificação dos RNF



RNF do Produto: Produto deve comportar-se de
forma particular (velocidade de execução,
confiabilidade, etc.)
RNF Organizacionais: Conseqüência de políticas e
procedimentos organizacionais (padrões de
processo usados, requisitos de implementação, etc.)
RNF Externos: Conseqüência de fatores externos
ao sistema e ao processo de desenvolvimento
(legislação, etc.)
RNF do Produto






RNF de usabilidade: usuários devem ser capazes de usar as
funções do sistema após duas horas de treinamento
RNF de confiabilidade: o sistema deve estar disponível
99% das vezes
RNF de segurança: o acesso aos dados deve ser protegido,
conforme RN
RNF de desempenho: o sistema deve processar n
requisições por segundo
RNF de capacidade: o sistema deve suportar n usuários
concorrentemente
RNF de portabilidade: o sistema deve rodar nas
plataformas X e Y
RNF Organizacionais




São procedentes de políticas e procedimentos nas
organizações do cliente e do desenvolvedor:
RNF de entrega: um relatório de progresso deve
ser entregue a cada duas semanas
RNF de implementação: o sistema deve ser
implementado na linguagem Java
RNF de padrões e métodos de desenvolvimento:
uso de métodos orientados a objetos;
desenvolvimento utilizando a ferramenta X
RNF Externos




Impostos tanto ao produto quanto ao processo de
desenvolvimento em função do ambiente no qual o
sistema é desenvolvido:
RNF de interoperabilidade: o sistema deve interagir
com os sistemas X e Y
RNF de restrições éticas: o sistema não deverá revelar
aos operadores nenhuma informação pessoal dos
clientes
RNF de restrições legais: o sistema deverá armazenar
as informações de acordo com a Lei número XXYY de
ZZ
Exercício

1.
2.
Forneça alguns exemplos de requisitos não
funcionais (RNF) para, classifique-os:
Vídeo Locadora
Sistema de Auto-atendimento Bancário
Requisitos de Domínio



Derivados do domínio da aplicação e descrevem
características do sistema e qualidades que
refletem o domínio
Podem ser gerar requisitos funcionais novos ou
restrições sobre os existentes
São regras de negócio (RN)
Problemas

Entendimento
 Requisitos
são descritos na linguagem do domínio da
aplicação
 Não é entendido pelos engenheiros de software que
vão desenvolver a aplicação

Aspectos Implícitos
 Especialistas
no domínio entendem a área tão bem que
assumem que os requisitos estão claros para os
desenvolvedores
Exemplos



[RN1] Os campos referentes a “Orçamento Projeto
Vinculado” só estarão ativos se o tipo de projeto
for Vinculado.
[RN2] O campo Valor Total Orçado para o Projeto
é calculado somando-se os valores definidos para
todas as rubricas incluídas no orçamento do projeto,
seja ele vinculado ou não-vinculado.
[RN3] A soma dos percentuais a ser distribuído
entre os fundos incluídos no plano de aplicação
deve ser entre 0 e 100%
Exercício

1.
2.
Forneça alguns exemplos de requisitos de domínio
(RN) para:
Vídeo Locadora
Sistema de Auto-atendimento Bancário
Respostas

Vídeo locadora:
 [RN1]
O software deve permitir que o cliente alugue
no máximo 2 filmes na primeira locação.

Sistema de Auto-atendimento Bancário:
 [RN1]
O cliente pode sacar o valor máximo de R$
100,00 por dia.
Processo de ER



Ambiente ideal: clientes e engenheiros de software
trabalhando juntos na mesma equipe.
Neste caso, a ER é simplesmente uma questão de
conduzir conversas entre colegas que são membros
bem conhecidos da equipe.
Exemplo: Desenvolvimento ágil de software.
Processo de ER


Ambiente real: clientes em cidade ou país diferente,
com uma vaga idéia do que é necessário, opiniões
conflitantes sobre o sistema a ser construído,
conhecimento técnico limitado, tempo limitado para
interagir com o engenheiro de requisitos, etc.
Nada disso é desejável, mas são situações comuns em
que a equipe de software é forçada a trabalhar.
Processo de ER


Trata dos passos necessários para conduzir a
Engenharia de Requisitos.
Busca colocar o projeto em andamento e mantê-lo em
movimento até se alcançar uma solução bemsucedida.
Início do Processo
Identificação dos interessados
Com quem mais vocês acham que
eu deveria falar?
Interessado: qualquer um que se beneficie de modo direto ou indireto do
sistema que está sendo desenvolvido.
O engenheiro de requisitos deve criar uma lista de pessoas que fornecerão
entradas à medida que os requisitos forem levantados.
Início do Processo

Diferentes pontos de vista

Requisitos inconsistentes e conflitantes

O engenheiro de requisitos deve categorizar todas as
informações dos interessados a fim de que os tomadores de
decisão escolham um conjunto de requisitos consistente.

Busque a colaboração entre os interessados.
Início do Processo



Primeiras questões
Engenheiro de Requisitos:
 Quem solicitou?
 Quais são os usuários?
 Qual o benefício econômico?
 Há outra fonte para a solução?
Equipe de Software:
 Quais são as saídas geradas?
 Qual o ambiente de negócios da solução?
 Restrições de desempenho afetarão a solução?
Início do Processo

Primeiras questões

Você é a pessoa certa para responder a essa questões?
Suas respostas são “oficiais”?

Alguém mais pode fornecer informações adicionais?
ATENÇÃO: Essas e outras questões ajudam no início da
comunicação, entretanto, não abuse delas durante as
reuniões.
Levantamento de Requisitos

Coleta colaborativa de requisitos
Especificar o problema
 Propor elementos da solução
 Negociar abordagens
 Especificar um conjunto inicial de
requisitos

Reuniões
Levantamento de Requisitos



As reuniões são conduzidas e assistidas por engenheiros
de software, clientes e outros interessados.
São definidas regras para a preparação e a
participação. É sugerida uma agenda suficientemente
formal para cobrir todos os pontos importantes, porém
suficientemente informal para encorajar o livre fluxo de
idéias.
Um “facilitador” (cliente, desenvolvedor ou outra pessoa)
controla a reunião.
Levantamento de Requisitos


Um “mecanismo de definição” é usado (folhas de
rascunho, flip charts, quadro de avisos eletrônico,
fórum virtual, etc).
A meta é identificar o problema, propor elementos
da solução, negociar diferentes abordagens e
especificar um conjunto preliminar de requisitos da
solução.
Levantamento de Requisitos

Quais são os produtos finais desta etapa?
 Declaração
da necessidade e viabilidade
 Escopo do problema
 Clientes, usuários que participaram
 Lista de requisitos
 Conjunto de cenários de uso (descrição de como o
sistema será usado)
 Protótipos
Análise de Requisitos

Objetivo
 Estabilidade
 Elementos
do modelo à medida que ele evolui
do Modelo de Análise
 Elementos baseados em cenários. Exemplo: casos
de uso
 Elementos
baseados em classes. Exemplo:
diagramas de classes
 Elementos comportamentais. Exemplo: diagramas
de seqüência
 Elementos orientados a fluxo
Negociação


Funcionalidades e desempenho podem
questionados em função do custo e do prazo
ser
Clientes (necessidades satisfeitas) e desenvolvedores
(orçamentos e prazos realistas) ganham.
“Conciliação é a arte de dividir um bolo de tal modo que
todos acreditam ter o maior pedaço.” (Ludwing Erhard)
Negociação

A arte da negociação
 Reconheça
que não é uma competição
 Trace uma estratégia
 Ouça atentamente
 Focalize os interesses das outras partes
 Não deixe a coisa ficar pessoal
 Seja criativo
 Esteja pronto a se comprometer
Validação
Requisito consistente com o objetivo, sem
restrições contraditórias?
 Requisitos estão especificados em um nível de
detalhes suficiente?
 Todas as funções foram incluídas?
 Há necessidade do requisito?
 Ambigüidade? Requisitos conflitantes?
 Requisitos podem ser testados?

Levantamento de Requisitos



Técnicas de Validação
Revisões de requisitos: podem ser formais ou informais. As
revisões formais devem ser conduzidas através da verificação
da consistência, erros e completeza do requisito.
São verificadas também:
 facilidade de verificação;
 facilidade de compreensão;
 adaptabilidade: alterações no requisito podem provocar
efeitos significativos?
Gerenciamento de Requisitos
 Requisitos
para grandes produtos são modificados
freqüentemente
 Diversidade
prioridades)
de
usuários (diferentes requisitos e
 Restrições
orçamentárias e organizacionais X requisitos
dos usuários finais
 Modificações
 Impacto
na empresa e no ambiente técnico
das mudanças do requisito (facilidade de
rastreamento)
O Processo de Engenharia de Requisitos
Estrutura de um Documento de
Requisitos










Prefácio
Introdução
Glossário
Definição dos Requisitos do Usuário
Arquitetura de Sistemas
Especificação de Requisitos do Sistema
Modelos de Sistema
Evolução de Sistema
Apêndices
Índice
Atividade


Praticando o Processo de Engenharia de Requisitos.
Cada grupo será responsável por elaborar um
documento de requisitos para um dos domínios abaixo:
 Locadora de Vídeo
 Universidade
 Atendimento ao cliente
 Algum
outro domínio escolhido pelo grupo deve ser
apresentado previamente ao professor.
Orientações Gerais






Elaborar um documento de requisitos com base nas
tarefas de concepção, levantamento, elaboração,
negociação, especificação, validação e gestão de
requisitos.
Grupos de até 5 alunos
Apresentação na próxima aula
Duração: 5 minutos
Entregar documento de requisitos (até 4 páginas),
conforme o modelo entregue ao Aluno.
Dica: definir um papel para cada integrante do
grupo. Exemplo: gerente da empresa, usuário final,
engenheiro de software, desenvolvedor, etc.