Engenharia de Software
Processos de Engenharia de Requisitos
Abr/2010
Objetivos – Engenharia de Requisitos
Criar e manter um documento de requisitos do Sistema.
Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos (Aula anterior) Validação de Requisitos
Objetivos – Engenharia de Requisitos
Criar e manter um documento de requisitos do Sistema.
Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos Validação de Requisitos
Estudo de Viabilidade Entrada:
Conjunto preliminar de requisitos de negócio Esboço da descrição do sistema Como o Sistema apoiará o negócio
Saída Relatório que recomenda ou não prosseguir com os processos
de Engenharia de Requisitos e de Desenvolvimento de Sistemas
Estudo breve que responde: Sistema contribui para os objetivos gerais da organização Sistema pode ser implementado com
Tecnologia atual Restrição de custo Restrição de prazo
Sistema pode ser integrado aos outros Sistemas
Estudo de Viabilidade
Possíveis questões a serem levantadas:
Como seria se esse sistema não fosse implantado? Problemas com os processos atuais e como o novo sistema
ajudaria? Contribuição direta do novo Sistema para os objetivos da
empresa? As informações podem ser transferidas e recebidas de outros
sistemas da organização? O Sistema requer Tecnologia ainda não usada na
organização? O que deve ser apoiado pelo Sistema e o que não deve ser
apoiado?
Estudo de Viabilidade
Consulta: Gerência de Departamentos onde o Sistema será usado Outros desenvolvedores familiarizados com o Sistema proposto Especialistas em TI Usuários Finais
Relatório de Viabilidade Pode Propor:
Mudanças de escopo Mudanças de orçamento Mudanças de prazo Sugestões de requisitos de alto nível adicionais
Objetivos – Engenharia de Requisitos
Criar e manter um documento de requisitos do Sistema.
Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos Validação de Requisitos
Levantamento e Análise de Requisitos
Trabalham com clientes e usuários finais do Sistema:
Para aprender sobre o domínio da aplicação Quais serviços o Sistema deve fornecer Desempenho esperado Restrições de Hardware
Envolve qualquer pessoa ou grupo afetado pelo Sistema, direta ou indiretamente (stakeholder)
Levantamento e Análise de Requisitos
Detalhamento e Compreensão dos requisitos dos stakeholders é difícil por várias razões: Não sabem o que querem do Sistema a não ser em termos
gerais Não tem conhecimento dos custos envolvidos Expressam as necessidades em seus próprios termos e com o
conhecimento implícito de seu trabalho Diferentes stakeholders tem diferentes requisitos, expressos de
diferentes formas (pontos de convergência e conflitos) Fatores políticos Ambiente econômico e de negócios é dinâmico.
Levantamento e Análise de Requisitos
As atividades envolvidas em espiral
Atividades: Obtenção dos requisitos
Classificação e Organização dos requisitos
Priorização e negociação de requisitos
Documentação de Requisitos
Levantamento e Análise de Requisitos
As atividades envolvidas em espiral
Atividades: Obtenção dos requisitos
Classificação e Organização dos requisitos
Priorização e negociação de requisitos
Documentação de Requisitos
Levantamento e Análise de Requisitos
As atividades envolvidas em espiral
Atividades: Obtenção dos requisitos
Classificação e Organização dos requisitos
Priorização e negociação de requisitos
Documentação de Requisitos
Obtenção dos Requisitos
Processo que reúne informações sobre o sistema proposto e os existentes.
Fontes:
Documentação Stakeholders (entrevistas e observações) – Uso de cenários e
protótipos para auxiliar na obtenção dos requisitos. Especificações de Sistemas Similares Dominío da aplicação Outros sistemas que interagem com o Sistema
Obtenção dos Requisitos
Fontes de requisitos podem ser representadas como Pontos de Vista do Sistema, em que cada ponto de vista apresenta um subconjunto de requisitos do Sistema.
3 tipos genéricos de Pontos de Vista:
Ponto de Vista de interação – utilizam diretante. Ponto de Vista Indiretos – não usam, mas são afetados Ponto de Vista de Domínio (ex. padrões de comunicação de
daods)
Obtenção dos Requisitos
Identificar os Pontos de Vista relevantes pode ser difícil.
Para ajudar, tentar identificar tipos mais específicos de pontos de vista: Fornecedores e receptores de serviços do Sistema. Sistemas que tem interface. Regulamentos e padrões aplicáveis. Fontes de requisitos de negócio e não funcionais do sistema. Desenvolvedores do Sistema Marketing
Depois de identificados e estruturados, identificar os PV mais importantes e começar com eles a obtenção dos requisitos do Sistema.
Obtenção dos Requisitos
Entrevistas
Formal/Informal Questões sobre o sistema que eles usam e o Sistema a ser
desenvolvido. Fechadas / Abertas. Pré-roteiro. Úteis para:
Entendimento geral sobre o que os stakeholders fazem Como eles podem interagir com o sistema Dificuldades com os sistemas atuais
Obtenção dos Requisitos
Entrevistas
Difícil levantar o conhecimento de domínio durante as entrevistas devido a:
Terminologia e jargões específicos Alguns conhecimentos de domínio são tão familiares aos
stakeholders que são considerados difíceis de explicar ou não vale a pena mencionar.
Problemas também para levantar requisitos e restrições organizacionais.
Obtenção dos RequisitosCenários
Pessoas consideram mais fácil relatar exemplos do que abstrair descrições.Começa com um esboço da interação que será detalhada durante o levantamento.Inclui: Descrição do que os usuários esperam do sistema no início do
cenário Descrição do fluxo normal de eventos no cenário Descrição do que pode dar errado e como é tratado Informações sobre outras atividades que podem ocorrer
simultaneamente Descrição do estado do sistema ao final do cenário.
Podem ser escritos ou completados com diagramas, imagens de computador ou ainda uma abordagem mais estruturada como cenários de eventos ou casos de uso.
Obtenção dos Requisitos
Casos de Uso
Técnica baseada em cenários para elicitação de requisitos.
Identifica o tipo de interação e os agentes envolvidos.
Como enfocam as interações são eficazes para os requisitos de pontos de vista de interação, em que cada tipo de interação pode ser representado como um caso de uso.
Não são eficazes para restrições de requisitos de negócio e requisitos não funcionais de alto nível.
Obtenção dos Requisitos
Casos de Uso
Busca Artigos
Impressão Artigos
Adm Usuários
Serv. Catálogo
Usuário de Biblioteca
Fornecedor
Funcionários Biblioteca
Obtenção dos Requisitos
Etnografia
Técnica de observação para compreender os requisitos sociais e organizacionais.
Um analista se insere no ambiente de trabalho aonde o sistema será usado e observa o dia a dia.
Eficaz para: Requisitos implícitos do sistema que refletem os processos reais Requisitos derivados de como as pessoas realmente trabalham Requisitos derivados da cooperação e do conhecimento das
atividades das outras pessoas.
Objetivos – Engenharia de Requisitos
Criar e manter um documento de requisitos do Sistema.
Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos (aula anterior) Validação de Requisitos
Validação de Requisitos
Mostrar que os requisitos realmente definem o Sistema que o Usuário deseja.
Verificações de Validade – Necessidade do Sistema ou de mais funções ou características
Verificações de Consistência – Requisitos não conflitantes. Verificações de Completeza – O documento de requisitos deve
incluir todas as funções e restrições necessárias. Verificação de Realismo – Se podem ser implementados. Facilidade de Verificação – Os requisitos de sistema devem ser
escritos de modo que sejam verificáveis. Isto é, pode-se definir um conjunto de testes que possa demonstrar que o sistema entregue atende cada requisito especificado.
Validação de Requisitos
Revisões de Requisitos
É um processo manual que envolve pessoas de ambas as organizações. Eles verificam o documento de requisitos em busca de anomalias e omissões.Podem ser formais ou informais e com o maior número de stakeholders a confirmação dos requisitos.Os requisitos devem atender: Consistência Completeza. Facilidade de Verificação. Facilidade de Compreensão. Rastreabilidade. Adaptabilidade.
Gerenciamento de Requisitos
Processo para compreender e controlar as mudanças dos requisitos do sistema. Manter o acompanhamento dos requisitos individuais e manter as ligações entre os requisitos dependentes de modo que seja possível avaliar o impacto das mudanças de requisitos.
Requisitos de Sistema de Software sempre mudam. Normalmente Requisitos de Sistema são incompletos Durante o processo o entendimento dos Stakeholders muda. Depois de instalado surgem novos requisitos
Prioridades são mudadas Quem paga o Sistema é diferente de quem usa Ambiente de negócios e técnico do sistema muda.
Gerenciamento de Requisitos
Requisitos Permanentes e Voláteis
A evolução de requisitos durante o processo engenharia de requisitos e após a entrada em operação é inevitável.
Requisitos Permanentes – Relativamente estáveis derivados da atividade central da organização e que se relacionam diretamente ao domínio do Sistema.
Requisitos Voláteis. Ex: políticas do governo.
Gerenciamento de Requisitos
Planejamento de Gerenciamento de Requisitos
No gerenciamento de requisitos devemos: Identificação de requisitos – identificação única para referencia
cruzada e avaliações de rastreabilidade. Processo de Gerenciamento de Mudanças – Avaliação do
impacto e custo das mudanças. Política de rastreabilidade Apoio informatizado
Informações de rastreabilidade: Origem – stakeholders que propuseram e os motivos Requisitos – requisitos dependentes. Projeto – requisitos aos módulos de projeto, nos quais esses
requisitos são implementados.
Gerenciamento de Requisitos
Gerenciamento de mudanças de requisitos
O gerenciamento de mudanças de requisitos deve ser aplicado a todas as mudanças propostas aos requisitos.
Existem três estágios no processo: Análise do problema e especificação da mudança – Se existe o
problema e se a mudança é válida ou é realizado um maior detalhamento.
Análise da mudança e estimativa de custo – Efeito avaliado usando as informações de rastreabilidade e o conhecimento geral dos requisitos do Sistema.
Implementação da mudança – O documento de requisitos, o projeto e a implementação do Sistema são modificados.