Melhora da comunicação de requisitos resultou na -
redução de falha de projetos, - cumprimento de
prazos e - satisfação dos clientes;
Qnto + tarde identificar erro de requisito > será
o custo para sua correção
Requisito (IEEE Standard
610.12 -1990)
(1) é uma condição ou
capacidade necessária para
um usuário resolver um
problema ou alcançar um
objetivo;
(2) é uma condição ou
capacidade que deve estar
presente em um sistema para
satisfazer um contrato,
norma, especificação ou outro
documento formalmente
imposto;
(3) uma representação
documentada de uma
condição ou capacidade com em (1) e (2);
Stakeholders - Fonte de
requisitos; pessoas ou
organizações que tem algum
impacto (direto ou
indiretamente);
Engenharia de Requisitos (ER)
2 objetivos:
1) Conhecer os req. relevantes, estabelecer um
consenso entre os stakeholders, documentar e
gerenciar;
2) Compreender e documentar as expectativas e
necessidades dos stakeholders, minimizando o risco da
entrega ser incompatível as expectativas e necessidades;
4 atividades centrais:
1) Elicitação - obter em detalhes
os requisitos das fontes;
2) Documentação - documentar os req. da forma
mais adequada (linguagem natural e / ou modelos
conceituais)
3) Validação e Negociação
4) Gerenciamento - medidas para estruturar req. e
atividades para assegurar sua implementação
Modelos de Processos
Modelos Pesados
Waterfall / Cascata (Royce, 1987)
V (V-Modell, 2004)
Elicitar e documentar os req. em fase incial;
ER finita e restrita no tempo;
Modelos Leves
Extreme
Programming - XP
(Beck,1999)
ER como um processo contínuo e abrangente;
integra todas as fases do desenv. de sistemas
Fundamentos da Teoria de Comunicação -
Fatores que contribuem para transmissão dos
requisitos
A linguagem como meio de comunicação de req.
Tipo de meio de comunicação (verbal ou técnica escrita)
Acomodação linguística
Conhecimento implícito anterior ao tema
1.3 Características de um
Engenheiro de Requisitos
1) Raciocínio Analítico -
familiarizar-se com
domínios para
compreender necessidades
dos stakeholders
2) Empatia - boa
intuição e empatia para
compreender as
necessidades;
3) Competência comunicativa
4) Resolução de conflitos
5) Moderação - liderar discussões ;)
6) Auto-confiança - capacidade de se defender em meio as
críticas que irão surgir por estar no centro do processo
7) Persuasão - consolidar opiniões divergentes e facilitar tomada de decisões
1.4 Tipos de Requisitos
1. Req. Funcionais -
resultado de um
comportamento a ser
fornecido por uma função
do sistema;
2. Req. de Qualidade ou Req. não funcionais -
definem desempenho, disponibilidade ,
confiabilidade, escalabilidade, portabilidade de um
sistema. Relacionados a atributos de arquitetura do
sistema
1.5 Importância e Categorização dos Req. de Qualidade
- ser objetivos e verificáveis;
- devem ser documentados
separadamente dos req. funcionais;
3. Restrições -
uma condição do
projeto que deve
ser cumprida.
Ex.: prazo.
2. Os Limites do Sistema e do Contexto
Na ER o objetivo de definir os limites para
identificar a parte do ambiente que influencia
nos requisitos do sistema a ser desenvolvido
2.1 Contexto do Sistema
Parte da realidade que é
relevante para os
requisitos de um sistema
Exemplos: Pessoas, Sistemas em
operação, Processos, Eventos,
Documentos e Leis.
Definir o Limite do Sistema
Quais aspectos fazem parte do
sistema a ser desenvolvido e
quais fazem parte do contexto do
sistema?
é obrigatório esclarecer a zona cinzenta entre o sistema e o limite do sistema
Uma vez definidos os limites
do sistema estará
determinado o:
ESCOPO
engloba os aspectos que podem ser modificados
e projetados durante o desenvolvimento
apresenta as restrições para o sistema a
ser desenvolvido
Definir o Limite do Contexto
Quais aspectos tem alguma relação com o
sistema a ser desenvolvido e quais fazem
parte do ambiente irrelevante?
não é necessário e é impossível uma definição completa e precisa do limite
do do contexto , ou seja, determinar se aspectos isolados do ambiente
influenciam ou são influenciados pelo sistema
Identificar interfaces
(interações) do sistema
com seu ambiente
Fontes - fornecem dados de entrada
(inputs) ao sistema. Ex.: grupos de
stakeholders;
Destinos - recebem dados de saída
(outputs) . Ex.: processos e sistemas;
Zona cinzenta
frenquentemente o limite do sistema não é
definido até o final da ER
limite do sistema e o contexto não está claro
Documentar o Contexto do Sistema
1. Diagrama de Casos de Uso (Jacobson, 1992)
2. Diagrama de Fluxo de Dados (DeMarco, 1978)
3. Diagrama de Classes UML (OMG 2007)
3. Elicitar Requisitos
Fontes de Requisitos
1. Stakeholders
Gerenciar stakeholders mantendo uma planilha com
dados referentes a pessoa e ao projeto
Transformar stakeholders que antes eram apenas
afetados pelo projeto em colaboradores
Acordos individuais - permite contornar situações desgastantes e
formalizar acordos, responsabilidades, canais para feedback
2. Documentos
3. Sistemas em operação
3.1.2 Lidar com os Stakeholders no Projeto
Direitos e deveres do Engenheiro de Requisitos:
1. Falar a linguagem dos stakeholders;
2. Familiarizar-se inteiramente com o domínio
da aplicação;
3. Criar documento de requisitos;
4. Ser capaz de apresentar resultados de trabalho (diagramas; gráficos);
5. Manter um relacionamento respeitoso com os stakeholders;
6. Apresentar suas ideias e alternativas bem como seus resultados;
7. Permitir que os stakeholders demandem propriedades do sistema que venham
a simplificar e facilitar a utilização;
8. Assegurar que o sistema atenda as exigências funcionais e de qualidade dos stakeholders;
9. Planejar e organizar os canais de comunicação;
10. Elaborar cronograma com as atividades de requisitos junto com os stakeholders;
Direitos e deveres dos Stakeholders
1. Introduzir o Engenheiro de Req. no domínio da aplicação;
2. Suprir o Engenheiro de req. com requisitos;
3. Documentar cuidadosamente os requisitos;
4. Tomar decisões em tempo hábil; (HA-HA-HA)
5. Respeitar as estimativas de custo e viabilidade feitas pelo Engenheiro de Req;
6. Priorizar requisitos;
7. Inspecionar os requisitos que o Engenheiro de Req. documentou;
8. Comunicar imediatamente a mudança de requisitos;
9. Aderir ao processo de mudança previamente determinado;
10. Respeitar o processo de ER implantado;
3.2 Categorização de Requisitos conforme o Modelo de Kano
(1) Fatores BÁSICOS de satisfação (dissatisfiers) - conhecimentos subconscientes
São propriedades evidentes e
pressupostas que o sistema deve
ter e sem as quais o cliente ficará
insatisfeito
Técnicas de observação
e centradas em
documentos
(2) Fatores ESPERADOS de satisfação (satisfiers) - conhecimento consciente
São propriedades explicitamente
exigidas do sistema.
Técnicas de Pesquisa
(3) Fatores INESPERADOS de satisfação (delighters) -
conhecimento inconsciente
o stakeholder surpreende-se
positivamente ao utilizar o sistema
Técnicas de criatividade
3.3 Técnicas de Elicitação
Influenciam na escolha da técnica de elicitação:
1. a distinção entre req.
conscientes, subconscientes e
inconscientes a serem elicitados;
2. as restrições referentes a
tempo, orçamento e
disponibilidade dos stakeholders;
3. a experiência do Engenheiro
de Req. com a técnica;
4. oportunidades e riscos do projeto;
Técnicas de Pesquisa
1. Entrevista - o Engenheiro de Req. faz perguntas e
documenta as respostas;
Prós: perguntas bem pensadas são
capazes de revelar req.
subconscientes e extraí respostas
completas para requisitos;
Contras: muito tempo consumido;
2. Questionário - útil quando há um grande nº de participantes;
Prós: podem elicitar grande nº de informações em curto
tempo e baixo custo;
Contras: exige elevado domínio sobre o assunto e não permite
retroalimentação imediata para adaptar e corrigir perguntas
mal formuladas;
Técnicas de Criatividade
Servem para desenvolver req. inovadores ou
esboçar uma visão inicial e fatores inesperados de
satisfação
Prós: permite o surgimento de soluções e coletar muitas
ideias em curto tempo;
Contras: não é tão eficaz qndo a dinâmica é confusa ou os
participantes muito dominantes
2. Brainwriting / 6-3-5 ( + eficaz quando há pessoas
muito dominantes)
Seis participantes escrevem 3 ideias em uma folhas -> folha repassada ->
participantes comentam e desenvolvem as ideias -> processo se repete 5
vezes;
3. Brainstorming Paradox
Identifica riscos e medidas preventivas através de ideias
coletadas sobre eventos que não devem acontecer
4. Mudança de Perspectiva (ex.: Método dos 6
chapéus) - abordar o problema dobre diferentes
perspectivas
Prós: benéfico qndo o stakeholder está preso a
opiniões;
Contras: se os requisitos exigem elevado grau de detalhamento a
utilização dessa técnica torna o processo exaustivo
5. Técnica de Analogia (biônica/ bissociação)
problemas do projeto são comparados a uma situação
análoga que acontece na natureza (biônico) ou não
(bissociação)
Contras: exigem muito tempo e conhecimento
sobre o tema sobre o qual a analogia será feito
Técnicas Baseadas em Documentos
permite elicitar sistemas legados e
deve ser combinada co m outras
técnicas para identificar novos
requisitos
1. Arqueologia do Sistema - pode ser feita a
partir de doc. ou códigos do sistema legado
Prós: permite identificar funcionalidade do sistema legado
Contras: exige muito trabalho e tempo
2. Leitura baseada em perspectiva - um qndo documentos
exigem uma perspectiva específica (ex: de um testador)
3. Reutilização - req. previamente compilados e atualizados conforme um padrão
Técnicas de Observação
Prós: próprias para stakeholders sem disponibilidade ou que não conseguem se
expressar de forma clara; facilita a proposta de melhorias; elicitar fatores básicos de
satisfação e facilita o conhecimento da linguagem
1. Observação de Campo - o Engenherio de Req.
acompanha e documenta os processos observados,
formulando, em seguida, os requisitos;
2. Aprprenciting - o Engenheiro de req. atua como um aprendiz do stakeholder
Técnicas de Apoio
compensam eventuais pontos
fracos da técnica selecionada
1. Mapas mentais para Braisntormings;
2. Workshops;
3. Class Responsability Collaboration (CRC) -
fichas de arquivo
4. Gravações de áudio e vídeo
5. Modelagem de casos de uso
6. Protótipos
4. Documentar Requisitos
Objetivos
1. Estruturar a vasta qtdade de requisitos
2. Facilitar a compreensão para a
vasta compreensão para não
envolvidos no projeto
3. Facilitar a localização e mudança de requisitos
perspectivas dos requisitos
1. Perspectiva estrutural
- dados de entrada e saída
- relações de dependência
entre o sistema e o contexto
2. Perspectiva Funcional
- dados que são recebidos e
processados;
- ordem de execução das funções
3. Perspectiva Comportamental
- reações do sistema frente a eventos
- condições que justificam
transições de estados
Documentação de Req. usando Linguagem Natural
é mais usada na prática; prosa livre
Prós: fácil compreensão pelo stakeholder; pode
ser usada para diferentes finalidades;
Contras: pode resultar em ambiguidade; dificulta
separa os tipos de requisitos
Documentação de Req. usando Modelos Conceituais
Prós: + compacto; compreensão
fácil; menor grau de
ambiguidade;
Contras: exigem conhecimento específico da modelagem ; não podem ser
utilizados universalmente; retratam somente uma perspectiva;
Tipos de diagramas importantes
1. Diagrama de casos de uso - visão geral das funções do sistema
2. Diagramas de Classes - modelagem estrutural dos dados
3. Diagrama de Atividades - sequência de atividades
4. Diagrama de estados - transição de estados desencadeados por eventos
Documentação híbrida de requisitos
combinação da linguagem natural e
modelos conceituais para amparar as
desvantagens e a associar as vantagens
Estrutura Padronizada de Documento
(3 + amplamente utilizadas)
Rational Unified Process (RUP)
método orientado a objetos
utilizada estrutura de especificação
de requisitos (SRS)
IEEE Standard 830 - 1998
estrutura padrão
sugere dividir o doc. em
3 capítulos:
Introdução - ex.: metas do
sistema / limites do sistema
Descrição Geral - ex.:
características dos usuários
restrições do desenvolvimento;
Requisitos Específicos - ex.:
requisitos funcionais, de
qualidade;
Modelo V - define diferentes estruturas
de acordo com o autor do documento
de requisitos
Especificação de Req. do Cliente ou
Caderno de Encargos - é criado pelo
contratante e descreve :
O que é feito.
Para que algo é feito.
Especificação de Req. do Sistema ou Caderno de Obrigações - se baseia no
caderno de encargos e descreve como concretizar os requisitos e as restrições
do caderno de encargos.
Uso do documento de
requisitos
1. Planejamento (definição de marcos)
2. Projeto arquitetônico
3. Implementação
6. Gerenciamento do Contrato
4. Teste
5. Gerenciamento da Mudança
7. Uso e Manutenção do Sistema
Critérios de Qualidade
para Documento de
Requisitos
1. Não ambiguidade e consistência (IEEE 830) - não
contradição dos req. individuais
2. Estrutura clara / leitura seletiva
3. Modificabilidade e extensibilidade (IEEE 830) -
conteúdo e estrutura devem facilitar mudanças
4. Completude (IEEE 830) - inputs, fluxos de exceção, req.
de qualidade, gráficos, referências contribuem para a
completude
5. Rastreabilidade (IEEE 830)
Critérios Formais (IEEE 830) e critérios
que aumentam a aceitação por parte do
leitor
1. Acordado - validado pelo stakeholddder
2. Priorizado (IEEE 830)
3. Não ambíguo (IEEE 830)
4. Válido e atualizado
5. Correto (IEEE 830) - assegurar a compreensão
do stakeholder
6. Consistente (IEEE 830) - não se contradiz
7. Verificável (IEEE 830) - pode ser
testado ou mensurado
8. Realizável - desenvolvedor participa da definição do req.
9. Rastreável (IEEE 830)
10. Completo (IEEE 830)
11. Compreensível
2 regras fundamentais que
aprimoram a legibilidade dos
requisitos
1. Frases e parágrafos curtos
(até 7 frases)
2. Formular 1 req. por
frase - voz ativa
Glossário - é uma coleção de definições para
termos apresentando os seguintes
elementos:
Termos técnicos específicos do contexto;
Abreviações e acrônimos;
Conceitos do dia-a-dia
com sentido específico
no dado contexto;
sinônimos - termos que
possuem mesmo significado
homônimos - idêntico mas com
sentidos diferentes
5. Documentar Requisitos usando Linguagem Natural
Prós: não exige (supostamente)
tempo de preparo para ser lido e
compreendido; Aplicação
universal;
Contras: não tem estrutura formal; podem gerar
ambiguidade devido a interpretações motivadas pelas
diferentes 'bases de conhecimento' de cada leitor.
Para minimizar essas desvantagens devem ser usados templates de requisitos e
observar os efeitos transformacionais da linguagem nos requisitos
5 Efeitos transformacionais +
relevantes para ER
1. Nominalização - termo
resumido de um processo
complexo;
2. Substantivos sem indicador de referência
- ex.: o sistema deve apresentar os dados de
faturamento para o usuário - quais dados?
que usuário?
3. Quantificadores universais -
ex.: o sistema deverá mostrar
todos os conjuntos de dados em
cada menu;
4. Condições específicas de forma incompleta -
qndo é especificado somente o
comportamento para caso a condição seja
atendida e é esquecida o tratamento para a
exceção
5. Verbos de processo especificados de forma
incompleta - deve ser detalhada as condições
necessárias para atendimento do processo e evitar a
voz passiva. Ex.:Para logar um usuário os dados de
login são inseridos. Deveria ser: o sistema deverá
permitir ao usuário inserir login e senha usando o
teclado do terminal.
6. Documentar Requisitos Usando Modelos
Prós: compreensão mais rápida
devido as descrições gráficas
(imagens);
Modelos - para cada perspectiva existe a
linguagem de modelo conceitual adequada
7. Validar e Negociar Requisitos
Assegurar que os requisitos documentados atendam
aos critérios de qualidade previamente determinados
Técnicas para validação de requisitos
1. Parecer de especialista - revisão de
um colega;
2. Inspeção - processo rigoroso com papéis determinados;
3. Walkthrought - mais 'light' que inspeção, discussão das falhas de
qualidade identificadas em uma sessão em grupo
4. Leitura baseada em perspectiva
5. Validação por protótipos
6. Checklist
8. Gerenciar Requisitos
Objetivos
1. Assegurar a constante disponibilidade de req. e
informações relevantes durante todo o ciclo de vida do
produto
2. Estrutura as
informações relevantes de
forma apropriada
3. Assegurar o acesso
seletivo a essas
informações
Técnicas das seguintes categorias
1. Designar atributos aos requisitos;
2. Priorizar requisitos;
3. Rasteabilidade de requisitos;
4. Versionamento de Requisitos
5. Gerenciamento das mudanças de Requisitos
9. Apoio por Ferramenta
Ferramentas apoiam a tarefa do ER de armazenar as
informações de forma a satisfazer os critérios de qualidade
para o gerenciamento de requisitos.
Se diferenciam de acordo com as funcionalidade oferecidas
1. Ferramentas profissionais pra gerenciamento de requisitos;
A escolha deve ser cuidadosa para não
impactar desnecessariamente o processo de
introdução da ferramenta
2. Ferramentas de modelagem e padrão de escritório (ex.: word e excel)