Descrever as principais atividades de
engenharia de requisitos (RE) e seus relacionamentos
Introduzir técnicas para elucidação e análise
de requisitos de requisitos
Descrever validação de requisitos e o papel
de revisões de requisitos
Discutir o papel da gerência de requisitos no
suporte a outros processos de engenharia de requisitos.
Estudo de Viabilidade Elicitação e Análise de Requisitos Especificação de Requisitos Validação de Requisitos Modelos do Sistema Relatório de Viabilidade Requisitos de Usuário e Sistema Documento de Requisitos
Decide se o sistema é relevante ou não:
Se o sistema contribui para objetivos da
organização;
Se o sistema pode ser construído usando
Se o sistema pode ser construído usando
tecnologia disponível e dentro do orçamento;
Se o sistema pode ser integrado com outros
Será que o sistema contribui para os
objetivos da organização?
Dadas as restrições tecnológicas,
organizacionais (econômicas, políticas,
ambientais, recursos disponíveis) e temporais ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema
pode ser implementado?
Caso haja necessidade de integração entre
Processo de aquisição de
informações sobre os sistemas
proposto e existente para gerar os
requisitos do sistema.
requisitos do sistema.
Fontes de informação incluem:
documentação, stakeholders do
sistema e especificações de sistemas
similares.
Stakeholder – qualquer pessoa que terá alguma
influência direta ou indireta sobre os requisitos do sistema
Problemas:
◦ Stakeholders não sabem o que querem exatamente. ◦ Stakeholders expressam requisitos em sua própria ◦ Stakeholders expressam requisitos em sua própria
linguagem.
◦ Diferentes stakeholders podem ter requisitos
conflitantes.
◦ Fatores políticos e organizacionais podem influenciar
nos requisitos do sistema.
◦ Requisitos mudam durante o processo de análise.
Novos stakeholders surgem e o ambiente do negócio muda.
Clientes do Banco
Representantes de outros bancos Gerente do Banco
Pessoal do caixa Pessoal do caixa
Administradores de Banco de Dados Gerentes de Segurança
Departamento de Marketing
Engenheiros de manutenção de Hardware e
software
Se o novo sistema não fosse implementado, quais
seriam as alternativas para a organização?
Quais são os problemas que os sistemas atuais
apresentam e como é que um sistema novo irá resolver estas falhas?
resolver estas falhas?
De que forma é que o sistema irá contribuir
diretamente para os objetivos da organização?
É possível a integração com os outros sistemas da
organização (de um ponto de vista tecnológico)? Com que facilidade é que se consegue partilhar informação entre estes sistemas?
Pontos de Vista são uma forma de estruturar
os requisitos para representar as perspectivas de diferentes stakeholders. Stakeholders
podem ser classificados sobre diferentes podem ser classificados sobre diferentes pontos de vista.
Esta análise de perspectiva múltipla é
importante visto que não existe uma única forma correta de analisar requisitos do
Em uma entrevista formal ou informal, a
equipe de RE questiona os stakeholders sobre o sistema que usam e o sistema a ser
desenvolvido. desenvolvido.
Existem 2 tipos de entrevista
Entrevistas fechadas, onde um conjunto
prédefinido de questões são respondidas.
Entrevistas abertas, onde não existe uma agenda
pré-definida e um conjunto de questões são exploradas.
Normalmente uma mistura de aberta e
fechada.
Boas para adquirir um entendimento geral
daquilo que os stakeholders querem que o sistema faça e como poderiam interagir com sistema faça e como poderiam interagir com o sistema
Não são boas para entendimento de
requisitos de domínio:
◦ Engenheiros de requisitos podem não entender
terminologia específica do domínio;
◦ Alguns conhecimentos do domínio são tão
familiares que as pessoas acham difícil articular ou não acham necessário explicar.
Entrevistadores devem ser abertos e
dispostos a escutar os stakeholders e não devem ter idéias pré-concebidas sobre os requisitos.
Devem abordar o entrevistado com uma
Devem abordar o entrevistado com uma
questão ou uma proposta e não devem simplesmente esperar que responda a questões do tipo “o que você quer?”.
Exemplos reais de como um sistema pode ser
usado.
Devem incluir
Uma descrição do início da situação;
Uma descrição do fluxo normal de eventos;
Uma descrição do fluxo normal de eventos; Uma descrição do que pode dar errado;
Informações sobre atividades concorrentes;
Uma descrição do estado do sistema quando uma
Cientistas sociais gastam um tempo
considerável observando e analisando como as pessoas trabalham.
Pessoas não precisam explicar ou articular
seus trabalhos. seus trabalhos.
Fatores sociais e organizacionais de
importância podem ser observados.
Estudos de etnografia têm mostrado que o
trabalho é usualmente rico e mais complexo do que o sugerido por modelos simples.
Requisitos que são derivados da forma como
as pessoas de fato trabalham ao invés da
forma como está especificado que deveriam trabalhar.
Requisitos são derivados da cooperação e
Requisitos são derivados da cooperação e
Demonstração de que os requisitos que
definem o sistema correspondem ao que o cliente realmente quer.
Custos relativos a defeitos de requisitos são
altos, tornando validação uma atividade de altos, tornando validação uma atividade de grande importância.
O custo de correção de defeitos de requisitos
após a entrega de um produto pode ser até 100 vezes maior do que o custo da correção de um defeito de implementação. Por quê?
Validade. O sistema provê as funções que
melhor dão suporte as necessidades de seus clientes?
Consistência. Existem conflitos nos
requisitos? requisitos?
Completude. Todas as funções requisitadas
pelo cliente estão incluídas?
Realismo. Os requisitos podem ser
implementados de acordo com o orçamento e a tecnologia disponíveis.
Verificabilidade (Testabilidade). Requisitos
Revisões de Requisitos
Análise manual sistemática. Prototipagem
Usando um modelo executável do sistema Usando um modelo executável do sistema
para checar requisitos.
Geração de Casos de Teste
Desenvolvimento de testes para requisitos a
Processo de gerenciar mudanças de
requisitos durante o processo de engenharia de requisitos e desenvolvimento do sistema.
Requisitos são usualmente incompletos e
inconsistentes: inconsistentes:
Novos requisitos aparecem durante o
processo na forma de requisitos de negócio e um melhor entendimento do sistema
acontece;
Diferentes pontos de vista possuem
diferentes requisitos algumas vezes contraditórios.
A prioridade dos requisitos para diferentes
pontos de vista muda durante o processo de desenvolvimento.
Clientes do sistema podem especificar
requisitos usando uma perspectiva do requisitos usando uma perspectiva do negócio que entra em conflito como requisitos do usuário final.
Ambientes de negócio e técnicos do sistema
Requisitos Permanentes. Requisitos estáveis
derivados de atividades centrais do cliente. Por exemplo, um hospital sempre terá
médicos, enfermeiras, etc.
Requisitos Voláteis. Requisitos que mudam
Requisitos Voláteis. Requisitos que mudam
durante o desenvolvimento ou quando o sistema está em uso. Em um hospital, requisitos derivados de políticas de tratamento de saúde.
Identificação dos requisitos (ID)
Identificação de cada requisito para cruzamento
de informações
Processo de gerenciamento de mudanças
Workflow para avaliação do impacto e custo das
Workflow para avaliação do impacto e custo das
mudanças (5.4)
Políticas de rastreabilidade Apoio de ferramentas CASE
Relacionamentos entre requisitos, suas
fontes e o projeto do sistema
Rastreamento de Fonte
Links dos requisitos para os stakeholders que os
propuseram; propuseram;
Rastreamento entre requisitos
Links entre requisitos dependentes;
Rastreamento de projeto
Links de requisitos para os módulos de projeto
Armazenamento de Requisitos
Requisitos devem ser gerenciados em uma base
de dados segura e gerenciável Gerenciamento de Mudanças
O processo de gerenciamento de mudança é um
O processo de gerenciamento de mudança é um
workflow cujas etapas podem ser definidas e o fluxo de informações entre estas etapas pode ser parcialmente automatizado.
Gerenciamento de Rastreamento
Recuperação automática de links entre
Análise do Problema e Especificação da
mudança
Verifica-se se a proposta de mudança é válida
Análise da Mudança e Estimativa do custo
Análise da Mudança e Estimativa do custo
Avalia-se o efeito da mudança e estima-se o
custo
Implementação da mudança
Documento de requisitos, projeto e
