Engenharia de Requisitos Mestrado em Ciência da Computação Disciplina: Engenharia de Software Profa. Dra. Elisa H. M. Huzita
Requisitos Requisitos: (IEEE) 1)Uma condição ou uma capacidade de que o usuário necessita, para solucionar um problema ou alcançar um objetivo. 2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente. 3) Uma representação documentada de uma condição ou capacidade, conforme os itens (1) e (2).
Engenharia de Requisitos está relacionada com a identificação de metas a serem atingidas pelo sistema a ser desenvolvido; está relacionada com a operacionalização de tais metas em serviços e restrições (princípios, técnicas, linguagens e ferramentas) ; está interessada com o relacionamento desses fatores para fazer uma especificação do comportamento do software e de sua evolução ao longo do tempo. é uma área ampla e multidisciplinar: aspectos sociais e humanos são importantes
Níveis de Requisitos Requisitos do usuário: Se destinam às pessoas envolvidas no uso e na aquisição do sistema; Devem ser escritos usando linguagem natural, tabelas e diagramas de modo que sejam compreensíveis. Exemplo:o software deve oferecer um meio de representar e acessar arquivos externos criados por outras ferramentas
Níveis de requisitos Requisitos do sistema: Se destinam a comunicar, de modo preciso as funções que o sistema tem de fornecer. Podem ser escritos: em linguagem estruturada, formulário estruturado de linguagem natural, linguagem com base em alguma linguagem de programação linguagem especial para especificação de requisitos
Níveis de requisitos Exemplo: para o requisito do usuário definido no item anterior, pode-se ter: 1.1. O usuário deve dispor de recursos para definir o tipo dos arquivos externos; 1.2 Cada tipo de arquivo pode ter uma ferramenta associada a ele; 1.3 Cada tipo de arquivo externo pode ser representado como um ícone específico na tela
Tipos de requisitos Principais tipos: Requisitos funcionais: dizem respeito à definição das funções que um sistema ou um componente de sistema deve fazer. descrevem as transformações a serem realizadas nas entradas de um sistema ou em um de seus componentes, a fim de que se produzam saídas. devem ser consistentes e completos Exemplo: o sistema fornecerá telas apropriadas para o usuário ler documentos no repositório de documentos.
Tipos de requisitos Requisitos não funcionais: dizem respeito às: restrições, aspectos de desempenho, interfaces com o usuário, confiabilidade, segurança, manutenibilidade, portabilidade, Padrões. são críticos: erros na elicitação destes se constituemn os mais caros e difíceis de corrigir, uma vez que um sistema tenha sido implementado
Tipos de requisitos Requisitos organizacionais: dizem respeito às metas da empresa, suas políticas estratégicas adotadas, os relacionamentos entre os seus atores junto com seus respectivos objetivos
O processo de engenharia de requisitos Processo de engenharia de requisitos = {estruturado de atividades que são seguidas com o objetivo de derivar, validar e manter um documento de requisito}
propostas de modelos de processo: 1) elicitação, especificação e revisão
Modelo de Processo de Engenharia de Requisistos 1. Elicitação Problema Usuário comunicação Engenheira de Requisitos aplicação de métodos de aquisição de informação 'Enunciado do Problema' 2. Especificação aplicação de métodos de especificação 3. Revisão desafios aplicação de métodos de revisão e animação Projeto modificações 'Especificação de Requisitos' Usuário aprovação do documento comunicação Engenheira de Requisitos
Modelo de Processo de Engenharia de Requisistos 2) Proposta por Castro: elicitação de requisitos busca capturar os requisitos e obter conhecimento domínio do problema usa entrevista, descreve sistemas similares, se envolve no trabalho do usuário, observa, aprende e questiona, onsulta material existente só a entrevista não é suficiente. modelagem de requisitos, análise de requisitos obter uma especificação consistente e completa. validação de requisitos.
Modelo de Processo de Engenharia de Requisistos elicitação + validação de requisitos = fase de aquisição de requsitos, modelagem + análise de requistos = fase de especificação de requistos.
Modelo de Processo de Engenharia de Requisistos Segundo Castro, a elicitação de requisitos é uma atividade de aprendizagem: a) do comportamento de sistemas existentes ( incluindo: procedimentos manuais, engenharia reversa de software existente e interfaces) b) do comportamento do domínio do problema que está relacionado com o software a ser implementado, c) dos objetivos e restrições dos usuários (funcionais e organizacionais).
Modelo de Processo de Engenharia de Requisistos 3) segundo Pressman: as tarefas do engenheiro de requisitos : reconhecimento do problema, avaliação e síntese, modelagem, especificação e validação(revisão). reconhecimento do problema: entender os elementos básicos de acordo com a percepção do cliente/usuário. avaliação e síntese de solução: são criados modelos do sistema para melhor entender aspectos funcionais, de controle, de comportamento. modelo: fundamentação para o projeto de software e base para a criação da especificação para o software.
Modelo de Processo de Engenharia de Requisistos especificação: prover uma representação do software que possa ser revisada e aprovada pelo usuário. validação: descrição de critérios que demonstram que ocorrerá uma implementação satisfatória e que servirão como base para o teste. Se não é possível um protótipo, poderá ser produzido um Manual Preliminar do Usuário.
3) Atividades: descoberta análise negociação especificação requisito requisitos requisitos requisitos declaração necessidade documento especificação sistema existente requisitos sistema padrões usuários experiência domínio
Modelo de Processo de Engenharia de Requisistos 5) Modelo proposto por Kotonya e Sommerville fases : Elicitação, Análise, Documentação e Validação de Requisitos. modelo espiral: cada atividade do processo é repetida até que seja tomada a decisão de que o documento de requisitos pode ser aceito. as mudanças de requisitos são parte da fase de Gerenciamento de Requisitos. as atividades, consistem de processos iterativos e interrelacionados que podem cobrir todo o ciclo de vida do desenvolvimento de sistemas de software
Elicitação Elicitação: objetivos: obter conhecimento relevante para o problema - prover o mais correto entendimento de o que é esperado do software; descobrir os requisitos através de comunicação com os usuários: dificuldades derivadas da capacidade humana: armazenar e organizar grande quantidade de informaçõies; gerenciar conflitos.
Elicitação investigar e coletar informações sobre o sistema e a organização que o envolve; identificar as necessidades de diferentes classes de usuários. problemas: entender as reais necessidades do usuário: ponto de vista do usuário diferente do anlista --> formação distinta usuários não têm uma idéia precisa e explícita do sistema a ser desenvolvido dificuldade dos usuários em descrever o conhecimento que possui sobre o domínio do problema
Elicitação Como proceder: iniciar com encontro preliminar seguida de outra técnica de elicitação Pressman, no encontro preliminar: questões que enfatizam o cliente, os objetivos e os benefícios do sistema; questões que habilitam o analista a ganhar um melhor entendimento do problema e o cliente falar sobre a sua percepção
Elicitação Técnicas para elicitação: cenários: representar tarefas que executam e as que desejam executar Técnicas tradicionais: questionários, entrevistas, análise de documentação existente técnicas de elicitação de grupo: técnicas de dinâmica de grupo: brainstorming prototipação: quando existe alto grau de incerteza e necessita de um rápido feedback
Elicitação técnicas cognitivas: aquisição de conhecimento para sistemas baseados em conhecimento técncias contextuais: técnicas de etnografia e análise social.
Técnicas tradicionais para elicitação entrevistas: fonte produtiva de apuração de fatos podem ser usadas em uma ampla variedade de domínios, sendo a mais utilizada vantagem: volume de informações que podem ser elicitadas e desvantagem: tempo que elas consomem.
Técnicas tradicionais análise das características do sistema objeto: produz bons resultados e provê uma estrutura para a definição do problema. pode-se: obter informações dos problemas e fatores chaves do sucesso, definir os fatores que são críticos para o sucesso na execução de suas tarefas ou tomada de decisão.
Técnicas tradicionais métodos existentes nesta técnica: BSP (Business System Planning) - está baseada nos processos de negócios. Os requisitos são derivados dos objetivos do sistema objeto e da definição dos processos de negócio (problemas e fatores chave de sucesso).
Técnicas tradicionais CSF (Critical Sucess Factor) - as informações relevantes são derivadas dos fatores críticos para a operação e gerenciamento da organização (sucesso na execução de suas tarefas ou tomadas de decisões) E/M (End Means Analysis) - propõe a separação entre definição dos resultados ou saídas (produtos, serviços e informações) gerados por um processo organizacional, e a definição dos meios (entradas e processos) usados para executá-los.
Técnicas tradicionais Outras Técnicas: FAST (facilited application specification technique) combina: identificação do problema, negociação e especificação de um conjunto preliminar de requisitos. Diretrizes básicas: encontro de clientes e desenvolvedores em local neutro estabelecer regras para preparação e participação; é sugerida uma agenda cobrindo todos os pontos importantes e que encoraja o livre fluxo de idéias; facilitador (cliente,desenvolvedor, ou elemento externo) para controlar o encontro.
Técnicas tradicionais Estratégia de Loh combina entrevista e questionário, tendo como base um conjunto de perguntas que se relacionam entre si e são divididas em três níveis de detalhe: perguntas genéricas: tratam de aspectos gerais da organização (objetivos, divisões, clientes e fornecedores da organização); perguntas específicas: coletam informações mais detalhadas sobre aspectos da organização; perguntas sobre termos chaves: palavras ou verbos considerados importantes dentro do contexto, são identificados e fornecidos pelo usuário.
Técnicas tradicionais Estratégia de Gilvaz: aquisição de informações independente de domínio; está baseada nas técnicas de entrevista e análise do sistema objeto Objetivo: preenchimento de um modelo conceitual, representando aspectos do sistema objeto baseado nos três métodos : BSP (Business System Planning), CSF (Critical Sucess Factor) e E/M (End Means Analysis) Tipos de perguntas : de instanciação, de relação, de complementação, de investigação e de inconsistência.
Técnicas tradicionais Perguntas de instanciação: Qual a área funcional? seus objetivos? suas atividades? seus problemas? Quais são as decisões associadas à atividade? De onde provem a informação? Quais são os fatores críticos de sucesso em torno da atividade? problemas que impedem o fator crítico de sucesso? informações que garantem/apoiam o fator crítico de sucesso? Quais os elementos envolvidos na atividade?
Técnicas tradicionais Quais as características do elemento? descriçao do elemento? serviços que operam o elemento? usuários do serviço? Quais são as informações utilizadas pelo serviço? Quais são as etapas envolvidas na execução do serviço? restrições que limitam o serviço? Perguntas de relação procuram estabelecer novas relações: <informação> apóia <fator crítico>? <informação> apóia <decisão>?
Técnicas tradicionais Perguntas de investigação: questionam a existência de informações não mencionadas. <fator crítico> é válido? Existe mais algum objetivo além da <lista de objetivos>? Existe mais algum fator crítico além de <lista de fatores críticos>? Existe mais alguma informação que apóia <fator critico> além da <lista de informações>? Existe mais alguma característica do <elemento> além da <lista de características>?
Técnicas tradicionais Perguntas de inconsistência: alertar inconsistências ocorridas a respeito de uma resposta: A <informação> foi respondida anteriormente como sendo fornecida por <origem>! Confirma? A <descrição> foi estabelecida anteriormente como <descrição do elemento>! Confirma? Outras perguntas podem ser definidas a partir de heurísticas derivadas do próprio modelo, que analisam as respostas alimentadas no modelo e procuram relações que façam sentido.
Elicitação Resultado da elicitação de requisitos: descrição dos requisitos que estabelece o que o sistema deverá fazer, auxilia na atividade de especificação de requisitos, mas não propõe uma solução para o problema
Análise e Negociação dos Requisitos análise: objetivo: detectar incompletudes, omissões e redundâncias - descobrir os requisitos necessários e desejados técnicas utilizadas: lista de checagem, prototipação
Análise e Negociação dos Requisitos negociação: objetivos: resolver conflitos entre usuários sem comprometer asatisfaçãodecadaum; atribuir prioridades aos requisitos ----> de acordo com as necessidades dos usuários; atender aos requisitos mais críticos
Documentação Documentação: objetivo: documentar os requisitos deve ser possível de entender por todos ----> contrato entre usuários e desenvolvedores; deve ser rastreável e gerenciável ao longo da evolução do sistema; descrever restrições, interfaces com outros sistemas, descrição do domínio.
Validação de Requisitos validação de requisitos: objetivos: certificar que o documento de requisitos é consistente com as necessiddes dos usuários, verificar a validade, a consistência, a completeza, o realismo; a facilidde de verificação. dificuldades: obter consenso entre usuários com objetivos conflitantes demonstrar a corretude
Validação de Requisitos dificuldades: obter consenso entre usuários com objetivos conflitantes demonstrar a corretude técnicas usadas: revisão de requisitos protitipação
Gerenciamento de requisitos gerenciamento de requisitos objetivos: gerenciar e controlar as mudanças nos requisitos gerenciar o relacionamento entre os requisitos os requisitos devem ser identificados unicamente ---> possibilitar restrear e avaliar os impactos advindos de mudanças
Mais técnicas para elicitação e 1) Cenários: o que são: validação descrições em linguagem natural ou modelos mais complexos contendo informação comportamental (ações, eventos e atividades) e objetos (entidade, atributos) objetivos: descrever as ações em um ambiente relacionadas ao sistma atual ou a um sistema a ser desenvolvido
Mais técnicas para elicitação e validação o cenário pode incluir: descriçãodo estadodosistemanoiníciodocenário; descrição do fluxo normal de eventos no cenário; descriçãodoque pode sair errado e de como lidar com isso; informações sobre outras atividades que possam estar em andamento ao mesmo tempo; uma descrição do estado do sistema no final do cenário exemplo: ( cenário do evento) iniciar transação: solicitar senha, validar usuário e selecionar serviço
exemplo.. o cliente insere o cartão e digita a senha. Se o cartão for válido, o controle poderá passar para o próximo estágio. Existem 3 possíveis exceções ( para cada um posso ter uma descrição detalhada e o cenário correspondente): tempo esgotado: não forneceu a senha dentro do tempo permitido cartão inválido: não é reconhecido e é devolvido cartão roubado: cartão é reconhecido como cartão roubado e é retido na máquina.
Mais técnicas para elicitação e validação principais técnicas utilizando cenários: 1) métodos para a análise de requisitos baseda em cenários: Hipótese: a integração de técnicas fornece o melhor caminho para a engenharia de requisitos técnicas utilizadas: entrevistas e técncias para descobrimento de fatos: elicitar dados suficientes para a construção de protótipo
Mais técnicas para elicitação e validação construção de protótipo: pode usar qualquer ferramenta validação com clientes: utilizar protótipos para validar os requisitos análise: efetuar a análise dos requisitos alguns pontos: combinação de técnicas é útil na captura de requisitos; a utilização de cenários na descrição de situações auxilia a manter a atenção dos clientes; cenários são fracos para captura de requisitos não funcionais.
Mais técnicas para elicitação e validação 2) Use case: baseados em cenário para a obtenção de requisitos 3) Etnografia: técncia de observação que podeser utilizada na compreensão dos requisitos sociais e organizacionais. o analista observa o trabalho diário in loco. ajuda a descobrir requisitos implícitos, que refletem processo reais ( muito além daquilo que consta na definição de um processo)
Mais técnicas para elicitação e validação 4) orientado a pontos de vista: sistemas de médio ou grande porte--> diferentes tipos de usuários --> diferentes interesses nos requisitos --- >diferentes pontos de vista os diferents pontos de vista são utilizados para estruturar e organizar o processo de levantamento e os próprios requisitos.
Mais Técnicas para Elicitação e validação Vantagens: a utilização do sistema é heterogênea: diferentes usuários pode ser usada para coletar e classificar informações de diferentes tipos de domínio de aplicação, pode ser usado como um meio para estruturar o processo de elicitação de requisitos pode ser usado para encapsular diferentes modelos de sistema pode ser usado para estruturar descrição de requisitos e expor conflitos entre os diferentes requisitos.
Princípios de Especificação de Requisitos Os usuários e os interesses: clientes : validação dos requisitos. analistas : consistencia, completude e corretude (na especificação). garantir a integridade do sistema (no projeto). os projetistas e engenheiros: nos requisitos (é a base para a construção do sistema) o gerente de projeto: administrativas contidas nos requisitos e também restrições de tempo e necessidades do cliente.
Princípios de Especificação de Requisitos Conteúdo de uma Especificação de Requsitos: 1) Funcionalidade: descrevem os serviços que devem ser fornecidos para o cliente/usuário: procedimentos para inicializar, finalizar, testar osistema; operações sobre condições normais /anormais; procedimentos para controlar os modos de operação /recuperação do sistema 2) Descrição do Ambiente e Objetivos do Sistema: objetivos do sistema: razões fundamentais para ter um sistema de computação.
Princípios de Especificação de Requisitos descrição do ambiente no qual o sistema irá operar e o domínio da aplicação. Contém, informações tais como: atributos físicos do ambiente (tamanho, localização); atributos organizacionais (aplicação comercial, aplicação militar); tipos de usuários em potencial; aspectos de segurança; mudanças no ambiente que irão perturbar a operação do sistema,etc..
Princípios de Especificação de Requisitos 3) Gerenciamento de Projeto: garantir que a construção do sistema será realizada de uma maneira cuidadosa e controlada. Tratam: a) do ciclo de vida do desenvolvimento: como ocorrerá a construção do sistema e contém: padrões de documentação; procedimentos para teste e integração dos módulos; procedimentos para o controle das mudanças e mudanças conjecturadas/esperadas. b) da entrega e instalação do sistema, considerando os processos que ocorrem fora do escopo de construção e incluem informações do tipo:
Princípios de Especificação de Requisitos prazos de entrega; critério de aceitação; treinamento; manuais; suporte e manutenção. 4) Restrições Funcionais: descrevem as propriedades necessárias ao comportamento sistema e incluem: performance; eficiencia; segurança; confiabilidade; qualidade. do
Princípios de Especificação de Requisitos 5) Restrições de Projeto: são algumas condições, além da funcionalidade, que influenciariam o projeto e a construção do sistema: padrões de hardware e software; uso de bibliotecas específicas; uso de um sistema operacional específico questões de compatibilidade. 6) Protocolos de Dados e Comunicação: descrevem todos os tipos de fluxo de dados entre os componentes funcionais do sistema, e entre o sistema e seu ambiente. Isto inclui:
Princípios de Especificação de Requisitos Características Desejáveis em uma Especificação de Requisitos: Não ambiguidade: ter interpretação única Completude: descrever cada apecto significativo e relevante do sistema e incluir detalhes a respeito de todas as informações. melhor juiz = usuário, mas este nem sempre sabe muito além das funcionalidades e objetivos. natureza subjetiva da definição de completude esta propriedade é impossível de ser garantida;
Princípios de Especificação de Requisitos Consistência: não deve existir requisitos contraditórios na especificação; Verificabilidade: deve ser possível verificar o que projeto e implementação originais; satisfazem os requisitos Validação: possibilitar ao usuário de ler e entender a especificação de requisitos, e indicar se os requiatos refletem as suas idéias; Modificação
Princípios de Especificação de Requisitos Compreensível: todos os usuários devem ser capazes de entender os requisitos; Teste: possibilitar quye sejam realizados testes; Rastreamento: estabelecer referências entre os requisitos, aspectos de projeto e implementação, para possibilitar controlar os efeitos das modificações.
Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-1993 1.Introdução 1.1 propósito do documento de requisitos 1.2 escopo do produto 1.3 definições, acrônimos e abrviações 1.4 referências 1.5 visão geral do restante do docuemnto 2.Descrição geral 2.1 perspectiva do produto 2.2 funções do produto 2.3 características do usuário 2.4 restrições gerais 2.5 suposições e dependências
Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-1993 3. Requisitos Específicos os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do sistema, especificar requisitos lógicos de banco de dados,restrições de projeto, caracterísitcs de qualidade. 4. Apêndices 5. índice
Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-1993 Este padrão é bastante amplo As informações incluídas em um documento de requisitos depende do tipo de software que está sendo desenvolvido
Formato de documento de requisitos sugerido em [Sommervile 2002] 1. Prefácio: define o público a que se destina o docuemtno, descreve seu histórico de versão, l gica para criação da versão e um sumário das mudanças feitas 2. Introdução: descreve brevemente cada função e explica como deverá operar com outros sistemas. Descreve como o sistema se ajusta aos negócios em geral e aos objetivos estratégicos da organização que está encomendando o software.
Formato de documento de requisitos sugerido em [Sommmervile, 2002] Glossário: definir os termos técnicos utilizados no documento Definição de requisitos do usuário: os serviços fornecidos para o usuário e os requisitos não funcionais. A descrição pode ser em linguagem natural, diagramas ou outras notações. Padrões de produtos e processo a serem seguidos devem ser especificados. Ex. O editor deve fornecer um recurso aos usuários para adicionar nós de um tipo específico a seu desenho
Formato de documento de requisitos sugerido em [Sommervile 2002] 5. Arquitetura de Sistemas: apresenta visão geral da arquitetura com possíveis módulos. Os componentes reutilizados, se houverem, devem ser indicados 6. Especificação de requisitos do sistema: descrever requisitos funcionais e não funcionais, podendo incluir interfaces com outros sistemas.
Formato de documento de requisitos sugerido em [Sommervile 2002 7. Modelos do sistemas: elaborar um ou mais 8. Evolução do sistema: descrever mudanças previstas devida à evolução de hardware, mudnças ns necessidades do usuário 9. Apêndices: podem incluir descrições de configurações de hardware; requisitos de BD 10. Índice: alfabético, diagramas
Comentários Adicionais O Contexto da Definição de Requisitos: 1) Elementos Fundamentais: Ambiente ou domínio da aplicação: O que é: é onde ocorrem os fenômenos que caracteerizam os problemas referentes aos requisitos do cliente. É o primeiro elemento a ser conhecido e representado pelo engenheiro de requisitos. Incluem aspectos sociais, economicos e políticos em que se insere a organização
Comentários Adicionais Características: Cultura organizacional: regras, comportamento, hábitos e costumes Mudanças: dinâmica social e organizacional do elemnto humano como agente de mudança do ambiente; Tecnologias: avanços tecnológicos e o impacto que causam no ambiente organizacional
Comentários Adicionais Problemas: O que são: diferença : algo como desejado x como percebido Características: Fato: verdade Fenomeno:como se vê Fato + fenomeno + quem relata : possibilita entender um problema
Comentários Adicionais Requsitos: O que são: declaração descritiva de exigências do ponto de vista de alguém sobre o qual será provida tecnologia de informação para a solução do problema Características: Funções Atributos Restriçoes (critéios para aprovação ou recusa para um produto)
Comentários Adicionais Stkeholder: Quem são: pessoas que direta/indiretamente são afetadas pelo sistema a ser construído para a solução de problemas Características: Preferências Expectativas Prioridade
Comentários Adicionais Processo de Engenharia de Requisitos Envolve: a aplicção de técnicas; métodos, normas e padrões e métricas e planejamento Produto: documento de requisitos Incluem: contexto organixacional, requisitos, avliação de riscos.