Engenharia de Requisitos

Engenharia de Requisitos

Objetivos • Descrever as principais atividades da engenharia de requisitos • Introduzir técnicas para a elicitação e análise de requisitos • Descrever validação de requisitos • Discutir o gerenciamento de requisitos

Elicitação de requisitos e análise Estudo de viabilidade Especificação de requisitos Validação de requisitos Relatório de viabilidade Requisitos do usuário e do sistema Modelos do sistema Documento de requisitos O Processo da Engenharia de Requisitos

Estudo de Viabilidade • O que é um estudo de viabilidade? • O que estudar e concluir? • Benefícios e custos • Análise de custo/benefício • Alternativas de comparação

Estudo de Viabilidade • Estudo que indica se o esforço em desenvolver a idéia vale a pena • Visa tanto a tomada de decisão • Como a sugestão de possíveis alternativas de solução

Estudo de Viabilidade • Deve oferecer informações para ajudar na decisão • Se o projeto pode ou não ser feito • Se o produto final irá ou não beneficiar os usuários interessados • Escolha das alternativas entre as possíveis soluções • Há uma melhor alternativa?

O Que Estudar? • Sistema organizacional apresentado • Usuários, políticas, funções, objetivos, etc. • Problemas com o sistema apresentado • Inconsistências, funcionalidades inadequadas, performance, etc. • Objetivos e outros requisitos para o novo sistema • O que precisa mudar?

O Que Estudar? • Restrições • Incluindo requisitos não-funcionais do sistema (superficialmente) • Alternativas possíveis • Sistema atual é geralmente uma das alternativas • Vantagens e desvantagens das alternativas

Testes de Viabilidade • Operacional • Medida do grau de adequação da solução para a organização • Avaliação de como as pessoas se sentem sobre o sistema/projeto • Técnica • Avaliação da praticidade de uma solução técnica específica e a disponibilidade dos recursos técnicos e dos especialistas

Testes de Viabilidade • Cronograma • Avaliação de quão razoável está o cronograma do projeto • Econômica • Avaliação de custo-eficiência de um projeto ou solução • Conhecida como análise de custo/benefício

Viabilidade Operacional • Avalia a urgência do problema (visão e fases de estudo) ou a aceitação da solução (definição, seleção, aquisição, e fases do projeto) • Há dois aspectos da viabilidade operacional a serem considerados • O problema vale a pena ser resolvido ou a solução proposta para o problema funcionará? • Como o usuário final e a gerência sentem-se sobre o problema (solução)?

Viabilidade Técnica • A solução ou a tecnologia proposta é prática? • Já possuímos a tecnologia necessária? • Já possuímos o conhecimento técnico necessário?

Viabilidade de Cronograma • Dado nosso conhecimento técnico, os prazos dos projetos são razoáveis? • Alguns projetos são iniciados com prazos específicos • Você precisa determinar se os prazos são obrigatórios ou desejáveis • Se são mais desejáveis que obrigatórios, o analista pode propor outros cronogramas

Viabilidade Econômica • Talvez a mais crítica • Durante as fases iniciais do projeto, a análise da viabilidade econômica consiste em julgar se os possíveis benefícios de solucionar o problema são ou não vantajosos • Tão logo os requisitos específicos e soluções sejam identificados, o analista pode levar em consideração os custos e benefícios de cada alternativa • Isso é chamado de análise de custo-benefício

Tipos de Custos • Custos de desenvolvimento de sistemas • Desenvolvimento e aquisição • Custos de instalação e de conversão • Custos operacionais (contínuo) • Manutenção • Pessoal

Análise Custo-Benefício • Há três técnicas principais • Análise do retorno financeiro (payback analysis) • Retorno do investimento (return on investments) • Valor atual líquido (Net present value)

Análise de Retorno do Investimento • A técnica de análise de retorno do investimento (ROI) compara os benefícios das diferentes soluções ou projetos • O ROI para uma solução ou projeto é a taxa percentual que mede a relação entre a quantia que a empresa obtém de retorno ao seu investimento e a quantia investida

Análise de Retorno do Investimento • O ROI para uma solução ou projeto potencial é calculado como a seguir: • ROI = (Benefícios totais - Custos totais) / Custos totais • ROI = valor atual líquido / Custos totais • Ex: ROI = (22508,64-17321,20)/ 17321,20= 29,95% • EX: ROI = 5187,44/ 17321,20 = 29,95% • A solução que oferecer o ROI mais alto é a melhor alternativa

Matriz de Viabilidade • Como nós comparamos alternativas quando existem vários critérios de seleção e nenhuma das alternativas é superior em todos os aspectos? • Use uma Matriz de Análise de Viabilidade!

Relatório de Viabilidade • Após o esforço inicial, discutido anteriormente, deve-se elaborar um relatório de viabilidade • Para cada aspecto apresentado, deve haver seção de avaliação • Deve haver uma seção conclusiva sobre a melhor alternativa ou que o sistema não é viável

Exercício • Determine a viabilidade de (+ROI): • 1. Sistema para uma padaria de pequeno porte (Só caixa, no balcão também, etc.); • 2. Sistema inteligente de preenchimento do IRPF pela própria pessoa física; • 3. Sistema para gerar alocação de docentes, salas, horários, local de forma otimizada.

Elicitação de requisitos e análise • Esta atividade divide-se em dois esforços maiores: • Elicitação dos requisitos em si • Técnicas de elicitação • Análise do que foi elicitado • Processo de análise

Que é um requisito? • Tanto pode ser • Uma declaração abstrata de alto nível de um serviço • Como uma restrição do sistema • Quanto uma especificação funcional matemática detalhada

Elicitação de Requisitos • Também denominada de descoberta de requisitos • Envolve pessoal objetivando descobrir o domínio de aplicação, serviços que devem ser fornecidos bem como restrições • Deve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas no domínio, etc. (Stakeholders).

Visão dos Requisitos • Requisitos do Usuário • Declarações em linguagem natural com diagramas de serviços que o sistema deve oferecer e suas restrições operacionais. Escrito para os clientes • Requisitos do Sistema • Documento estruturado com descrições detalhadas sobre os serviços do sistema. Contrato entre cliente e fornecedor

Tipos de Requisitos • Requisitos Funcionais • Requisitos Não-Funcionais • Requisitos de Domínio

Requisitos Funcionais • Descreve funcionalidade e serviços do sistema • Depende do • Tipo do software • Usuários esperados • Tipo do sistema onde o software é usado

Exemplos de R.F. • [RF001] Usuário pode pesquisar todo ou um sub-conjunto do banco de dados • [RF002] Sistema deve oferecer visualizadores apropriados para o usuário ler documentos armazenados • [RF003] A todo pedido deve ser associado um identificador único (PID), o qual o usuário pode copiar para a área de armazenamento permanente da conta

Exercício • Dê alguns exemplos de R.F.s para: • 1. Sistema da padaria de pequeno porte; • 2. Sistema inteligente de preenchimento do IRPF; • 3. Sistema de alocação docente.

Requisitos Não-Funcionais • Definem propriedades e restrições do sistema (tempo, espaço, etc) • Requisitos de processo também podem especificar o uso de determinadas linguagens de programação, método de desenvolvimento • Requisitos não-funcionais podem ser mais críticos que requisitos funcionais. Não satisfaz, sistema inútil.

Requisitos Não-Funcionais • Devido à sua própria definição, requisitos não-funcionais são esperados mensuráveis • Assim, deve-se associar forma de medida/referência a cada requisito não-funcional elicitado

Medidas de Requisitos(Não-Funcionais) Propriedade Medida Velocidade Transações processadas/seg Tempo de resposta do usuário/evento Tamanho K bytes No de chips de RAM Facilidade de uso Tempo de treinamento No de 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 falha Percentual de eventos causando falhas Probabilidade de corrupção de dados após falha Portabilidade Percentual de declarações dependentes do destino No de sistemas destino

Classificação de R. N. F. • Requisitos do Produto • Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.) • Requisitos Organizacionais • Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.) • Requisitos Externos • Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.)

Exemplos de R. N. F. • Requisitos do Produto • [RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s • Requisitos Organizacionais • [RNF002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00 • Requisitos Externos • [RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema

Exercício • Dê alguns exemplos de R.N.F.s para: • 1. Sistema da padaria de pequeno porte; • 2. Sistema inteligente de preenchimento do IRPF; • 3. Sistema de alocação docente.

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 requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas • Se requisitos de domínio não forem satisfeitos, o sistema pode tornar-se impraticável

Requisitos de Domínio (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 • Implicitude • Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos

Requisitos de Domínio (Exemplo 1) • A desaceleração do trem deve ser computada através da fórmula Dtrem=Dcontrole+Dgradiente onde ...

Exercício • Dê alguns exemplos de domínio para: • 1. Sistema da padaria de pequeno porte; • 2. Sistema inteligente de preenchimento do IRPF; • 3. Sistema de alocação docente.

Requisitos Requisitos Usuário Sistema  Domínio Funcionais Não-funcionais Produto Externo Organização

Técnicas de Elicitação • Entrevistas • Questionários • Casos de Uso • Jogo de Funções • Brainstorming • Workshop de Requisitos

Entrevistas • Técnica direta • Pode ser usada na análise do problema e na elicitação de requisitos • Objetivo • Entender os problemas reais e soluções potenciais das perspectivas dos usuários, clientes, e outros stakeholders

Entrevistas • Quem são o cliente e o usuário? • Possuem necessidades diferentes? • Quais são suas • Capacidades • Backgrounds • Ambientes, etc. • Qual é o problema? • Como é resolvido atualmente?

Entrevistas • Qual a razão para resolvê-lo? • Qual o valor de uma solução bem-sucedida? • Onde mais uma solução pode ser encontrada? Note que algumas dessas perguntas já foram feitas no estudo de viabilidade.

Questionários • Aplicabilidade a mercados específicos • Onde perguntas são bem definidas • Hipóteses • Perguntas relevantes podem ser decididas antecipadamente • Leitor ouve da maneira desejada • Suprime o que é bom sobre análise • Úteis após uma entrevista inicial

Casos de Uso • Discuta com o cliente o que o sistema fará • Identique quem interage com o sistema • Identique que interfaces o sistema terá

Casos de Uso • Verifique se não há requisitos faltando • Verifique que os desenvolvedores entendem os requisitos • Vantagem é ter apelo visual dos requisitos mais relevantes do cliente

Jogo de Funções • Engenheiro de requisitos • Assume a função do usuário ou cliente • Entender o domínio do problema • Cliente • Assume a função do usuário • Entender os problemas que podem passar

Brainstorming • Regras para Brainstorming • Estabeleça o objetivo da sessão • Gere quantas idéias for possível • Deixe sua imaginação livre • Não admita críticas ou debates • Ajuste e combine as idéias

Workshop de Requisitos • Põe todos os stakeholders juntos por um período intensivo (focado) • Facilitador conduz a reunião • Todos têm sua vez de falar • Resultados são disponíveis imediatamente • Provê um ambiente para aplicar outras técnicas de elicitação

Engenharia de Requisitos